Accessibility Study of mHealth Systems Based on The Internet of Things (IoT)

The Internet of Things (IoT) has become part of people's daily life, allowing physical and digital contact. The rise of mobile devices and scientific and technological advances in health have led to breakthroughs in meeting consumer needs. mHealth refers to using mobile devices to improve healthcare services, increase medical care, and reduce costs. Mobile cloud computing (MCC) lets users bypass mobile device limits on processing, storage, and battery life. A body area network uses implanted wireless sensors to remotely monitor patients (WBAN). These networks collect and distribute data for disease diagnosis and prevention. This mix of technologies allows hospitals and clinics new ways to treat and monitor patients. This research examines IoT availability in mHealth. The analysed architecture includes wireless sensors to monitor patients, an intra-BAN, a mobile device with a battery and communication interfaces, an extra-BAN with Wi-Fi and 4G connectivity, and a cloud environment to store data. Hierarchical models were developed using RBD and continuous-time Markov chains (CTMC). Each component's MTTF (mean time to failure) and MTTR (mean time to repair) values are used to quantify system or section availability. Experiments were conducted to test mHealth availability parameters. Intra-BAN, Zigbee, or Bluetooth protocols have no meaningful impact on system availability. For households, two small routers in the extra-BAN are more effective than one large router. Finally, backup batteries and power banks boost availability. The offered models can help developers and maintainers scale mHealth systems based on service needs.


Introduction
The Internet of Things makes it possible for "things" to communicate with one another and with people in any location and at any time using any network or service [1]. By enabling simple access to and interaction with a variety of devices, the Internet of Things will encourage the creation of a number of applications that use the potentially enormous amount and variety of data generated by these objects to offer new services to citizens, businesses, and public administrations. [2]. Medical applications for remote health monitoring may emerge from the most alluring IoT application sectors, which are healthcare and medical care. Various medical sensors might be seen in this context as smart gadgets that are a crucial component of the IoT. IoTbased healthcare services must lower costs, enhance quality of life, and offer more enjoyable forms of treatment. Modern

System Evaluation
Sensor networks are used in remote health monitoring to collect data from patient and their surroundings. Patients with various diseases might be monitored at a hospital or at home. Figure 1 depicts an example of a generic mHealth system for remote patient monitoring over a body area network (WBAN). The system is based on a model developed by Testa et al. (2015) [8] that considers a patient who requires medical attention and has wireless sensors linked to his body. Bluetooth 802.15.1, Zigbee 802. 15.4, or 802.15.6 are commonly used standards. The data is transferred to the mobile cloud computing service via the mobile device's local and mobile WiFi network interfaces (extra-BAN communication). Incoming data is processed by cloud infrastructure. The patient communicates with the system via gadgets equipped with environmental sensors. The computer system analyses the sensor data. This information can be used by health practitioners to perform medical treatments and diagnose patients in crises or with stable situations. Patients can be monitored at home or while exercising, rather than merely in clinics or hospitals. It is preferable for medical sensor nodes to meet minimum size and weight requirements, to provide good processing power at an acceptable size for your application, to have low power consumption operating for long periods without the need to recharge the battery, and to use standards-based protocols with the option of calibration to measure values with the greatest possible precision. A significant parameter for predicting battery life is the rate at which network nodes collect and send raw data to the cloud. Continuously monitor the vitals of inpatients. Patients suffering from heart disease or undergoing surgery require 24-hour monitoring. These indicators can be checked every hour in stable patients [9].
A smartphone, tablet, or PC are examples of mobile devices. Smartphones can be used for exterior monitoring, whereas PCs can be used to monitor elderly people at home. To connect to the medical server, cellular networks or WLANs connect to an Internet access point. This communication enables you to send emergency notifications to a medical professional or an emergency medical service, send patient data on a regular basis, receive the health professional's care plan, make data available to patients' family members, and provide direct communication between patients and/or their families and a health professional [10]. The MCC environment may identify users, accept file uploads containing monitoring data, insert this data into medical records, analyse data trends, and notice key frame changes. It can be hosted in the medical centre or on a private cloud. Clinicians should seek medical advice. These can access patient data over the Internet, whether inside or outside the hospital. These data allow for vital sign monitoring for health maintenance (heart rate, blood pressure, body temperature, and so on), which is critical for intervention decision-making. This scenario could fail in In addition to these failures, the mobile device may have unavailable hardware and software at some point. The proposed scenario's components are modelled and subdivided to calculate their respective availabilities. The values discovered will be used as input parameters for the main components to determine the system's total availability.

Methodology of evaluation
A modelling and simulation problem can be solved in several steps. The methodology proposed in this section is based on the general methodology proposed in Obaidat and Boudriga (2012) for modelling and simulation. The procedure is depicted in Figure 2. • Understanding the system: First, understand the system. After the analysis, assumptions about the system's components, structure, and input parameters are made. Because the work focuses on dependability analysis, a base architecture is created and various experiments can be run to evaluate its availability. This is the conceptual model. The next steps of the methodology require a proper understanding of the system.
• Model implementation: The operating model is converted to a computer-readable format. Visualization tools help understand third-party models and results. These apps hide implementation details by organising data and allowing any-size structures. First, an RBD and Markov chains were used to create the system's hierarchical model (CTMC). Mercury and Wolfram Mathematica were used. The system model consists of five connected RBDs. A CTMC model discharged the phone's battery.
• Input parameter definition: Verify each model component's parameters in the literature. Mean failure and recovery times for wireless sensors, communication protocols, mobile devices, and cloud infrastructure are studied. Mobile device charge and discharge rates must be known. These last two parameters weren't discovered, so measurements were needed.
• Model execution and metric extraction: Next, run the models to check for errors. In cases of inconsistencies, reevaluate the models' functioning, parameters, and the need for additional experiments. Adjustments may include adding or removing components and changing model topology or design. Using metrics, you can evaluate system availability.
A value can be a parameter or metric depending on the analysis. Hierarchical models use X model metrics as Y model inputs. The smartphone's battery discharge is represented by a CTMC in the RBD model, and the result is an input parameter for the "battery" component.
• Results analysis: System availability is assessed by analysing and interpreting each model component's results. Existing and proposed battery models are compared. Also studied are WiFi redundancy strategies. Results can highlight system-impacting points and components. When presented in graphs and tables, results are easier to compare and analyse.

Metrics
Rechargeable batteries power most mobile devices. A battery is "an association of cells, accumulators, or capacitors connected together". A battery's storage capacity is expressed in mAh (milliampere-hour), which is the amount of charge available through a steady one-amp current over one hour. A 2000 mAh battery can receive 2000 milliamps per hour. If a device needs 500 milliamps, battery life is 4 hours. In our study, the smartphone will be our gateway. Several hardware and software factors, such as processor frequency, screen brightness, and running apps, can affect battery life. Depleted batteries can hinder system function, so they deserve attention.
Charge and discharge time is an input parameter for some models. In some cases, this time is used to measure how effective system-availability changes were. The main metrics are MTTF, MTTR, uptime, downtime, and availability. Sensors, mobile communication towers, router equipment, and smartphone and cloud infrastructure elements can calculate MTTF and MTTR. They represent component failure and recovery time.
These metrics measure a component's uptime and downtime. We can calculate how many hours two parallel routers can be offline in a year. Same goes for sensors monitoring a critically ill patient. Different levels of service uptime may be acceptable. mHealth systems must be highly available because they deal with patient health; they are usually measured in "number of 9s." System and component availability can be calculated. Increasing subcomponent availability increases system availability.

Measurements on the Mobile Device
Mobile device charging and discharging time affects availability values in evaluated scenarios. Know how long it takes to charge 10% of a battery with a wall charger and a portable power bank. Some data were missing from the literature, so input parameters had to be measured.
Based on the central limit theorem, all experiments collected at least 30 samples for all measurement parameters. This is the minimum acceptable sample size [12]. In these cases, the mean distribution is normal. Mean, SD, and 95% CI are calculated for each sample. Table 4 shows WiFi download data. This study used a Samsung M32 smartphone running Android 10.0.

Probability of Events
In the proposed models, some actions have probabilities, or an estimate of the chance an event will occur. In lieu of absolute certainty or denial for the occurrence of a certain event, a probability vector was used to consider as many system behaviours as possible. The probabilities of charging and replacing a discharged battery were estimated in this work based on the studied environment. It's possible to study the environment and measure these values more accurately in some cases. For this situation, you can survey the specification (antenna power and coverage range) and location of the router equipment. A hospital floor plan can map the entire facility. In the proposed location site, each black dot indicates the physical installation position of each router equipment, and the shaded circle determines signal propagation area. Some situations, like X-ray exam rooms, are shielded to prevent radiation leakage. Even with a router nearby, the WiFi signal can't get through. The same thing happens with 4G mobile signals, leaving users without wireless network access. A user may move from one router's coverage area to another. For a few moments, WiFi may go out, requiring 4G. Hospital WiFi signal coverage is 91.2%. The X-ray area, with no connection due to shielding, is 7%, while 1.8% of the total area won't have a local network signal, requiring a mobile network. Based on the proportion of covered areas and people, the values found can be used as probabilities of WiFi, no connection, and 4G use.

Models
This section describes the proposed mHealth system's operation and each element's role. The scenario was developed using a hierarchical model composed of RBD and Markov chain, covering five elements: sensor, intra-BAN  Figure 3 shows the system's RBD model. Series has five parts: I Sensor (SS) represents all sensors that monitor the patient and his environment, (ii) Intra-BAN (I-BAN) is communication between sensors within the body network area, (iii) mobile device (SP) acts as a gateway, or bridge to the external network, and (v) mobile cloud computing infrastructure (MC). Equation 1 expresses system availability as the product of subsystem availability. Each subsystem's component is essential to the system's functioning, so they're all connected in series. If one component is down, the system is down. Sensors (SS) can be single or combined for patient monitoring. Sensors can be standalone or in smartphones. In our approach, each sensor captures specific patient data relevant to the user's monitoring, so they are all connected in series. If a sensor fails, monitoring is compromised and the system is faulty. If the sensors have equivalent MTTF and MTTR values, an RBD model could use k-out-of-n, or for more complex conditions, CTMCs. For our purposes, we consider all sensors critical, so their failure causes the system to fail.
The Intra-BAN (I-BAN) component includes radio communication at about 2 metres around the human body, which can be divided into I body sensor communication and (ii) body sensor communication with the gateway. Due to the close relationship between BANs and body sensors, the system's communication architecture is crucial. Bluetooth and Zigbee are used for communication [8].
Our mHealth system model uses an RBD to assess smartphone availability. According to Araujo et al. (2014), this subsystem consists of mobile hardware (HW), mobile operating system (OS), battery (BAT), and mobile application (APP). Equation 2 expresses its availability. ASP = AHW × ASO × ABAT × AAPP …(Eq.2) Mobile hardware is the failing device. Mobile OS is the device's OS. The battery stores energy while the mobile app exchanges data with the cloud. The battery submodel is expanded. Any of these components failing renders the phone inoperable.
The Extra-BAN (E-BAN) component uses WiFi and mobile connections in parallel. If WiFi fails, the smartphone uses mobile data to avoid disconnecting the user. The RBD's parallel block arrangement represents this system's redundancy. Android's smart managers automatically switch between WiFi and mobile networks. The proposed models didn't account for this activation's short duration. Extra-BAN is unavailable only if both connections fail simultaneously.
We start with one WiFi and two 4G mobile connections. Formula 3 determines the E-BAN component's availability. If another type of connection becomes possible, the proposed model can be extended to n types of connections, and its availability will be calculated using Equation 3.
The model for representing the mobile cloud computing environment is the same one available in (

Battery Availability Model
Stochastic battery models use Markov chains to model charging and discharging as stochastic processes. CTMC is a model for sequential relationships. Charge unit states are used in the representation. The Markovian property states that regardless of process sequence, a future charge state depends only on the present state. The battery fails due to discharge. We use a Markov chain model based on battery charge states for this representation. Oliveira et al., (2013) [14] proposed an 11-state model with 10% discharge steps. The battery is unavailable in state "0," but all others are. According to the author, a 10% battery discharge takes 0.9 hours. The model assumes a backup battery to replace the depleted one. Our model is an extension of Oliveira et al., (2013) [14], in which we consider the likelihood of the user being able to recharge the mobile device's battery. This probability may be affected by the availability of a power outlet, wall charger, or portable charger (power bank). If charging is not possible, the model considers the possibility of having a fully charged spare battery. The CTMC model has n states that represent the percentage of battery charge. "100" indicates that the battery is fully charged, while "0" indicates it is unavailable. All but "0" have a battery. The transition between states affects the rate of charging, discharging, and battery replacement.
CTMC used Mathematica to find the model's closed formula for mobile device battery availability. The software could not generate the formula for a CTMC with ten states using an Intel Core i7-4510U processor and 8GB of DDR3 1600Mhz memory. The expression was discovered by generating closed formulas from a minimum number of states to the maximum number of states supported by the software without pausing execution. A general formula for calculating battery availability with n states was deduced from the formulas. The Markov chain represents the battery's availability when considering a single type of connection, such as 2G, 3G, 4G, or WiFi, and knowing that p is a divisor of 100. A. Battery availability is calculated using Equation 5 Where: • α is the discharge rate of p% with the mobile device in use; • n is equal to 100/p; • β is the charging rate of p% of the mobile device; • γ is the rate for changing the mobile device battery; • p is the probability that the user can charge the mobile device; • ω is the probability that the user has a spare battery. The number of CTMC states is defined by parameter p. For example, for p equal to 20%, we will have 6 states (100%, 80%, 60%, 40%, 20% and 0%). The transition from a state of higher charge to one of lower charge occurs under the discharge rate α of p% of the mobile device battery. Conversely, the transition from a lower to a higher state of charge takes place under a charging rate β of p% multiplied by the probability ρ of the user being able to charge the mobile device. Upon reaching the 0% state, the battery can be replaced and return to the 100% state at a replacement rate γ multiplied by the probability ω that the user has a spare battery. Depending on the user's location and movement around the environment, he may be using more than one type of connection, including the absence of connectivity. For this case, the total availability of the AT system will be given by Equation 6.
Where: • m is the number of connection types; • is the probability that the user is using connection type j; • is the availability for connection type j; The battery discharge model's probabilities aim to cover as many scenarios as possible, where a certain event may have a high, low, or partial probability. Equation 5 determines Aj for each connection type.
Signal oscillation and network searching use more battery power when users are mobile. Patients treated at home may lose WiFi connection due to interference from other wireless networks and use their carrier's mobile data network. Data transfer may be slower on a 4G network, draining battery power. Loading and unloading rates are directly related to the user's connection type. The RBD formula is cheaper than including all connections in a single Markov chain. It is important to note that, depending on the rate chosen for discharging p% of the mobile device's battery, Equation 5 resulting from the analysis of CTMCs can deal with models involving different amounts of states resulting in a chain with 11 states. For this example, we consider the approximate time for discharge of 1 hour and for a charge of 0.25 hour, where the rate is the inverse of time. Thus, the charge rate β = 4 and discharge rate of the mobile device in use α = 1, for Tamjeed Journal of Healthcare Engineering and Science Technology (TJHEST) Volume 1 (1): 2023 https://tamjed.com/ this value of p. The availability found for this configuration is 0.9914. For p = 25%, the generated chain contains 5 states.
Considering ω = 1, γ = 12 and ρ = 0, the values of the rates α and β are calculated proportionally to the values obtained for p = 10%. That is, if for p = 10% the value of α = 1 and β = 4, when p = 25% the equivalent rate α will be 0.4 and β = 1.6. We obtain an availability value equal to 0.9917. When p = 5%, we will have a representation with 21 states in the CTMC, Adopting the same values of ω = 1, γ = 12 and ρ = 0 and using the same reasoning as in the previous example to find the values of α and β for that p, the battery availability is equal to 0.9913, where α = 2 and β = 8. The difference between the results found for the chains with p equal to 5% and 10% is due to the simplification that occurs in the states of the models, which could be greater if the measurement for the loading and unloading of "p" were used instead of use division using a "p" base. The smaller the value of p, the greater the number of states of the generated chain and the more accurate the result found.

Case Study 1: Availability of Communication Interfaces in extra-BAN
In the Extra-BAN model proposed in this work, we consider the use of two connections for gateway communication: WiFi and mobile. The mobile data connection works over wide area networks. Communication towers are responsible for transmitting data. In turn, the WiFi connection is made through a wireless router device whose purpose is to receive the connection from the Internet service provider and create access to this network without the need for cables. The source of this connection can be an ADSL modem, antenna, 4G modem, among others. There are currently on the market several options of router equipment in the most diverse values. Specification differences are usually linked to wireless connection speed, antenna power, range, protocols and operating frequency ranges.
In this case study, the use of two different routers was analyzed: a small domestic one and a more robust one. The RBD model represents the Extra-BAN components. The WiFi MTTF and MTTR parameters were obtained directly from the home and robust (D-LINK, 2016) router device manufacturers website. The rates referring to the mobile network were obtained by collecting the failure and repair time for communication towers available in [15]. Table 5 gathers all these parameters.
The reference scenario uses a home router and 4G. This configuration is common. Some broadband providers provide the router. In case of equipment failure, 4G mobile ensures communication continuity. We're ignoring the 4G connection's activation time. In scenario 2, availability is calculated similarly to the reference scenario, but a more robust router is used. This equipment has a longer MTF than simpler models. Figure 4 shows scenario 3 with two parallel home routers and a parallel 4G connection. Equation 5.1 determines this scenario's A3 availability.  Comparing the values obtained for the availability of the first two scenarios with the third allows us to assess to what extent it is interesting to invest in a router with more resources, and consequently a higher acquisition cost, or to choose to keep the duplicated system with more devices. simple. The calculated values for MTTF, MTTR and the number of 9's for the three scenarios are grouped in Table 6. The last column shows the percentage increase in availability in number of 9's in relation to the reference scenario.  Figure 5 graphically represents the results obtained for the availability of the three scenarios described above expressed in number of 9's. Replacing the home router with a robust router increased availability by 1 number of 9s, or 6.26% over the initial scenario. However, the last scenario using two home routers in parallel instead of a single robust router, we obtained an increase in the availability value by 49.58% in relation to the reference scenario. This value equates to a downtime time during the year of 3.50E-8 hours. The choice of a router model or another is influenced by the cost of its acquisition, economically speaking, the best alternative is to choose the equipment that offers greater availability at a lower price. The same product may vary in price depending on where it is purchased, being influenced by factors such as tax burden and proximity to the manufacturing center. It is not the focus of this work to analyze issues involving cost, however, considering C the price of a simple domestic router and according to the availability in number of 9's found, it is possible to measure the cost x benefit of the equipment. As long as the value of two simple routers (2C) is not greater than the cost of a robust router, scenario (3) will always be the best option, tying high availability, equipment redundancy and lower implementation cost. It is important to make it clear that the availability found refers only to extra-BAN. When calculating system-wide availability, this value will necessarily be lower. Therefore, it is important to maintain high availability on this component.

Case Study 2: Energy Consumption
The second case study proposes to evaluate the impact of the changes promoted in the battery model proposed by Oliveira et al. (2013) and Oliveira and Maciel (2014). Battery discharge is represented by an eleven-state CTMC, with a discharge rate of 10% with the mobile device in use.
The model assumes that the user always has a spare battery to replace the completely empty battery. Also, it is not possible to partially recharge the battery. Figure 6 illustrates this model. In this model dw is the rate for discharging 10% of the battery with the device in use and rb represents the replacement rate of the discharged battery. Substituting the notation used in Formula 5 we obtain the mathematically equivalent formula expressed in Eq.7. In the model in question, the probability of having a spare battery is always 1 and the probability of partially recharging the battery has a value of 0. The values for and are respectively Tamjeed Journal of Healthcare Engineering and Science Technology (TJHEST) Volume 1 (1): 2023 https://tamjed.com/ © TAMJED PUBLISHER and 12. The availability result is calculated by the formula proposal is equivalent to the value found in the model in Figure 6 The energy consumption assessment model proposed in this study considers the possibility of recharging the mobile device's battery in any of the charging states. If this is not possible, only then is the battery replaced. This measure increases the availability of this component. As an integral part of the smartphone, its availability has increased, and consequently, the availability of the entire system has also increased. To find the values for discharging 10% of the mobile device's battery, measurements were carried out to measure the time spent in this process. For measurements, we consider the device with 50% screen brightness, screen always-on, Bluetooth connection activated and application running sending and receiving data from a public cloud. This procedure was repeated to find values referring to a download rate of 10% using WiFi and 4G mobile connections. The same experiment was carried out, this time to find the 10% charge rate of the battery using a regular smartphone charger. For this case, we found an average time of 17 minutes for the partial load of 10%.
Using Equation 5 to calculate battery availability, we compared the values found for the model proposed in this work in relation to the results obtained in [14], using the same parameters. The differential of our model is the addition of partial load probabilities. The study becomes more comprehensive by proposing probabilities for actions that interfere with battery discharge. For this case, the β parameter is necessary and represents the charging rate of 10% of the mobile device battery using a certain type of connection. The availability of the proposed model has increased by 3.91 the number of 9's. The graph in Figure 6 presents this comparison, where we consider "scenario A" the one proposed in Oliveira and Maciel [14] and "scenario B" our model.
The proposed model for energy consumption will influence the results of the availability analysis of the next two case studies. The values for the parameters ρ, ω express the probability of charging the mobile device and the probability of the user having a spare battery for replacement. Depending on the scenario, we will have different values influencing the final availability results. The definition of these values will be estimated according to each environment.

Conclusion
This study aimed to assess the performance of mHealth systems with sensors in a body area network. Models based on reliability block diagrams (RBDs) and continuous-time Markov chains were proposed to represent its components (CTMC). The models took into account the following factors: patient monitoring via wireless sensors, intra-BAN communication, mobile device communication, extra-BAN communication, and the cloud computing environment. In the analysis of the availability of the mobile device's battery, the modifications made in relation to the model proposed by Oliveira et al., (2014) [14] promoted an increase in the component's availability in 3.91 number of 9's. One of the changes to this model was the inclusion of the possibility of charging the smartphone at any stage of battery charge. High resolution screens, constant connectivity with multiple communication interfaces, graphics chips, and increasingly faster processing units are just a few factors contributing to these devices' high energy consumption. To avoid having the device unavailable, it is common practice for users to bring their wall chargers or even portable power bank batteries with them; thus, the proposed change in the model already corresponds to a common practice of the majority of users. As a result, the impact of this practice on system availability could be assessed. The availability of study results can assist mHealth system maintainers in scaling the environment based on the criticality of the scenario. Starting with the desired availability, or as defined by a service level agreement, it is possible to analyse which components impact availability and propose redundancy measures to improve the results.