Evaluation of Suitability of Current Industrial Standards in Designing Control Applications for Internet of Things Healthcare Sensor Networks

Abstract

Internet of Things (IoT) holds great promises for industrial, commercial, and consumer applications. While wireless techniques have matured with time and have gained the users’ confidence in relaying data containing qualitative as well as quantitative information, cynicism still exists on trusting them for applications involving control. The wireless protocols and techniques used for industrial control have proved their robustness. In this work we have attempted to test some aspects of feasibility on the use of wireless control involving such protocols for IoT healthcare sensor networks (IoT-HSNs). We conceptualized and simulated a 24-channel IoT-HSN model that includes biosensors as well as bioactuators. Currently, no protocol supporting control in such networks has been standardized. We tried to fit in the widely used WirelessHART (Highway Addressable Remote Transducer) industrial protocol for sensing as well as control in the model to test if it would work for a healthcare sensor network. We probed the performance of the model with respect to network parameters such as channels, bandwidth, Quality of Service (QoS) requirements, payload, transmission delays, and allowable errors. For the parameters considered, the results obtained from the model were encouraging, suggesting that WirelessHART fits the IoT-HSN control requirements according to this initial probe. The findings could provide useful insights for researchers working in the field of control in IoT-HSNs and for designers and manufacturers of IoT-HSN equipment.

1. Introduction

Internet of Things (IoT) has started proving itself to be a business changer for several industries due to connectivity in systems and products being manufactured. IoT is making its presence felt strongly in healthcare with obvious benefits to both, patients as well as providers. Wearable devices used to gather health data for patients, sportspersons, soldiers or first responders and mobile medical applications are more commonly seen applications of healthcare IoT. IoT helps hospitals in supplementing patient treatment by keeping a check on the location of patients, personnel, and medical equipment like hospital beds, infusion pumps, and doors through remote monitoring and communication. The IoT data can be passed on to analytic dashboards using technologies like near field communication, real-time location systems, Bluetooth or Wi-Fi.

Healthcare practitioners are diligently observing the progress of this trend to appreciate if the Internet of Things holds some promises for their future. IoT for healthcare involves the use of electronic biosensors that acquire or monitor physiological data and are linked to a public or private cloud, which empowers them to spontaneously trigger certain occurrences. IoT for telehealth entails transmission of health-associated information or services over the communications infrastructure. Telemedicine, which incorporates remote patient monitoring, as well as non-clinical elements of the healthcare structure, such as education, both fall in the purview of telehealth.

Tracking vital health information for some patients now involves a rising use of Internet-connected devices with data coming from monitors for temperature, blood glucose levels, fetal development, and cardiac activity, among others, while supporting interactivity with healthcare professionals. Smarter versions of such devices can convey more valuable data, reducing the necessity for direct patient–physician interaction. It is expected that in the following years, there will be an enormous upsurge in IoT products for healthcare, on the clinical side in addition to the back end, involving biosensors as well as bioactuators. Design of bioactuators entails a higher focus on subject safety, and it is important to carefully study their performance in an IoT-HSN application before declaring them safe for usage. In this paper, we present one such model that envisages biosensors and bioactuators in an IoT network and probe the performance of a wireless protocol for our design.

Healthcare Networks and Potential Applications of IoT-Healthcare Sensor Networks (HSNs)

IoT-HSNs can monitor physiological parameters of soldiers, sportspersons, astronauts or patients away from the hospital. Freedom of movement without the encumbrance of trailing wires is an important requirement in all these applications.

In the changing healthcare scenario prompted by IoT, during a care episode, patients today are likely to interact with a variety of multiple-connected devices. These devices keep transmitting information continuously to some centralized system irrespective of whether it is during their stay at a hospital or a short visit with their physician. The devices cover vitals monitoring equipment, smart beds, medication dispensing carts, and Magnetic Resonance Imaging (MRI) machines to name a few. Although these devices are not new, with the rising reputation of IoT medical devices, the number of endpoints being introduced into the healthcare domain is growing fast.

“Smart beds” for hospitals can detect the patient’s presence and adjust to ensure the right pressure and support for the patient without a nurse’s help. They can also sense if the patient is trying to get up. Cloud-based smart home medication dispensers can automatically upload data to alert the care team when medication has not been taken or for any alarming indicators.

A prominent use of wearable technology is in personal safety devices that can track a user’s location and send alerts for emergency assistance. IoT wearables could perfectly address the personal safety concerns pertaining to patients with health issues like stroke or conditions requiring multiple medications, risky situations like injuries or falls during personal activities, or impaired cognitive capabilities in the case of Alzheimer’s patients. Such wearables are also being combined with panic buttons for sending out timely and discreet SOS alerts, fall detection biosensors, and GPS and mobile apps for proactive condition monitoring and management. Use of such devices could extend from fragile seniors who live alone to schoolchildren, night-shift employees, lone workers, and hikers, thus benefitting many. There is a promising market for such IoT devices as they could also help deter crimes and reduce chances of personal injuries.

Biosensors offer the benefits of low-price, rapid, and easy to function investigative resources for applications in numerous fields such as environmental monitoring, food industries, and medical diagnosis. During a football game, electroencephalograms (EEGs) of football players can be monitored through special helmets with surface electrodes. Prolonged IoT-HSN monitoring using an unobtrusive setup can help record randomly occurring symptoms and events in Parkinson’s disease patients.

Although there is substantial research effort into IoT applications involving biosensors and bioactuators, there is no accepted standard protocol for ON/OFF control or continuous monitoring and control in these applications. Most researchers are working on application-specific legacy protocols for control purposes. This paper probes the possibility of using WirelessHART (Highway Addressable Remote Transducer), a well-known wireless control protocol widely used in industrial applications for IoT-HSN use cases involving control.

2. Prior Work

Substantial research has been done on reliability, energy consumption, and security aspects of wireless control. New ideas like IoT-HSNs introduce innovative implementations that require further probing with additional considerations. Not much research can be found on the applications or feasibility studies on real-time control for IoT-HSNs for a variety of reasons, the main reason being the involvement of live subjects.

The ISA100 committee has defined six classes with increasing order of priority for operations on process monitoring and control [1,2]. The operations are sensing the data, displaying and recording it, and providing the diagnosis, associated control, and emergency actions.

2.1. ON/OFF Control through Sensor Networks

In an interactive computer music generation system for dance performances [3], the dancers generated their own music through their dance movements using a wireless sensor network (WSN) made of Tmote sensor nodes with optical, laser, pressure, and acceleration transducers for dancer-tracking, controlling sound selection, and location-based digital signal processing.

In another experiment, the data from accelerometers attached to rings around a pianist’s fingers were relayed using a WSN to the base station for generating and controlling piano music. Further, IR sensors were tied up with a clarinet to respond to the clarinetist’s movements for controlling the sound from clarinet [4] using a WSN for signal processing control at the base station computer. Although the experiments involved multiple sensors, control was limited to ON/OFF at best. In addition to ON/OFF control, industrial, commercial, and consumer process monitoring and control applications need continuous control. WSNs are being increasingly deployed for such applications due to distinct advantages over traditional wired instrumentation and control automation for monitoring, control, and asset management. The possibility of control applications in medicine and healthcare is also being probed.

2.2. IoT-HSN Applications Involving Real-Time Control

It is projected that by 2020, death rates due to cancer might soar by 50%, taking healthcare costs up to 15 million [5]. Cancer cell monitoring using IoT-HSNs can influence early tumor identification with no biopsy and presents a timely evaluation for early therapy.

Biocompatible nanotubes can be used in the creation of bioactuators and smart biosensors, bone implants on stimulated growth, pointed drug delivery systems, heart attack temperature biosensors, and fabrication of artificial muscles with bioactuators.

Wireless control in IoT-HSNs could have a potential application involving an insulin injection bioactuator that dispenses the correct dose of insulin to a diabetes patient based on inputs from glucose biosensors.

Similar control application can be utilized for Parkinson’s disease (PD) patients. In patients in advanced stages of PD, an unsafe condition called “freezing” or “freezing of gait” is reported [6]. When a gait-freeze occurs, the patient seems to be stuck and cannot move feet or stand up from a sitting posture. There are no known causes of the ‘freezing’ and the start or end of a gait-freeze cannot be predicted. Such freeze may cause the patient to fall. Freeze episodes happen at random and at varying frequencies across patients. PD patients are given dopaminergic medicines in dose and frequency depending on the patient’s stage of PD. An IoT-HSN control application could use a bioactuator-driven injection system for this medicine as suggested by a measurement and supervisory system.

Related research on Smart Gait [7] uses biosensors in a smartphone to create an inexpensive gait tracking device. The biosensors measure variability of step length (SL) and step width (SW) to monitor, predict, and possibly prevent falls. Similar application could be in the case of ‘drop foot’ [8] in which the subject finds it difficult to move or lift the front part of foot causing drag while walking.

Prosthetic implants used in the hip and knee are susceptible to bacterial infections. A flow biosensor in the infected area could sense change in viscosity due to development of bacteria and signal a bioactuator switch in the prosthesis to release stored medicine.

Dakurah et al. [9] explored a variety of implantable bladder sensors in their work.

In Reference [10], a wireless bladder volume monitoring system was tested by Hung et al. The system uses a flexible capacitive-based strain sensor to monitor bladder urine volume with respect to changes in the sensor capacitance. The authors used a passive telemetry platform based on inductive coupling to power the sensor in vivo but did not discuss communication and control protocol, limiting themselves to just radio frequency (RF) energization in their work.

For an implantable bladder sensor that uses RF communication, a frequency in the low-MHz region provides a good compromise with respect to bandwidth and tissue absorption [9]. The approach in Reference [11] by Liao also focuses on the use of inductive coupling between internal and external coils for power transfer and energizing the in vivo circuitry, limiting the work to the final control element.

For treating chronic wounds, a smart wound dressing platform can be developed on a conformal flexible substrate that has electronics with physical, chemical, and biological modules for monitoring the wound physically and chemically and intervening [12].

Gastrointestinal lesions and ulcers that require localized medication can benefit from a smart capsule that can release location-specific medication in the GI (gastrointestinal) tract. The smart capsule uses magnetic actuation from an externally worn magnet or an implanted magnetic marker for a proximity fuse that empties the drug reservoir [13].

In Reference [14], Gensler et al. tested a wirelessly controlled implantable system for on-demand and pulsatile insulin delivery. The system comprises an implanted magnetically driven pump (MDP), an external control device (ECD), and a mobile app. The MDP consists of a plunger, a barrel, and drug reservoir for infusing the correct amount of insulin when required. The ECD external to the subject’s body can actuate the MDP with an electromagnet that is wirelessly controlled by the mobile app. The system uses Bluetooth protocol between the app and the in vivo MDP. While Bluetooth can be used for a single channel application as a sensing and control protocol, in Section 2 we discuss why it cannot work satisfactorily for an IoT-HSN with multiple channels.

The correct concentration of oxygen in solid tumors is an important factor that effects the efficacy of radiation therapy. Traditional techniques force patients to breathe an air mixture with higher oxygen content or breath pure oxygen in a pressurized room or tube as in hyperbaric oxygen therapy (HBOT). Maleki et al. [15] developed an implantable micro-oxygen generator (IMOG) for an in vivo application to place inside a pancreatic tumor. The IMOG was powered with an ultrasonic transducer external to the body through the human body tissue. After it was energized, the device would use water present in the tissue for in situ electrolysis to generate oxygen. The development is significant and apt for in-situ applications. However, the control protocol to handle and energize the ultrasonic power transducer as and when required itself has not been tested by the authors or focused upon in the paper.

Negra et al. [16] focused on applications and QoS requirements for networks used for remote healthcare monitoring, emergency rescue, disease detection and prevention, rehabilitation, biofeedback, and assisted living.

Zou et al. [17] mentioned the use of actuators for control of some body functions based on the information received from sensors or a body control unit but did not discuss the actuator or its working in detail.

The article by Movassaghi et al. discussed the importance of improving speed, accuracy, and reliability of communication of sensors and actuators in a body area network [18]. It also refers to a prior work on a ubiquitous healthcare application proposed by Wang and Park involving an actuator for pumping the right dose of medicine into a subject’s body [19].

Antonescu and Basagni [20] briefly mentioned the use of actuators for performing medicine administration on subjects based on sensor information or through user interaction.

In Reference [21], Madsen et al. briefly discussed the use of an actuator for stimulation and muscle activation, and another real-time application involving injecting insulin into the subject based on a drop in the glucose level.

None of the research work in [16,17,18,19,20,21] discussed anything about bioactuators, their working or design considerations, unlike in the present work. Also, almost none of these approaches discussed the network interface beyond the final control element. There is hardly any published work focusing on the network protocol for such applications or testing the suitability of one for creating a standard.

2.3. Industrial Wireless Control

A simple example of an industrial automation application is adjusting the flow rate of the coolant through the cooling jacket surrounding a reactor for a specific, desired outcome. The outcome is to sustain a constant preset temperature for the reactor housing, where jacket temperature is the controlled variable, attained through change in the coolant flow rate, temperature or both. In such a system, all the devices were traditionally connected using wires. A thermal sensor measures the jacket temperature and transmits it to a controller, which uses a special function to decide the adjustment of a valve to manipulate the flow rate of the coolant through the cooling jacket. The controller also transmits the output to control the valve, handles input variations, and generates an alarm for faulty conditions. Sensor data are also archived for future reference. If WSN is used for this application, sensing and action devices will communicate over wireless links with an access point (e.g., a gateway or router), connected to the control station through a wired or wireless system.

Process control applications have stringent requirements and are mostly mission critical. Failure of a critical process control loop can cause accidents and an unscheduled plant shutdown. Researches have indicated the compelling benefits of migrating to wireless sensor technology, but a cautious approach is adopted by process technicians, with initial applications focusing just on process monitoring instead of closed-loop process control, despite wireless control standards being available.

2.3.1. Benefits of Going Wireless

Wireless sensor and control networks are easy to maintain and have no wiring constraints. Wired systems encounter maintenance problems such as physical cable wear, corrosion, cable burns, freezing, wild animal damage, and cost incurred in replacement. Existing wired systems work well with new wireless systems and do not need to be changed completely either. An important consideration is the choice of a right protocol for the application in question.

2.3.2. Evaluating Bluetooth Protocol for Control Applications in an IoT-HSN

Although Bluetooth is a common wireless protocol for short-range personal area networks (PANs), it cannot be used as a process control protocol involving multiple channels in a network due to bandwidth limitations. Newer Bluetooth versions like 3.0 need other technologies like WiFi to attain their full claimed bandwidth and are hence not applicable to pure PAN applications.

While the symbol rate on Bluetooth transmissions is claimed to be 1 megabits per second, the real data rate at an application is much less than that. The achievable data rate on Bluetooth is affected by the packet type. Single-slot packets utilize one 625-microsecond slot and can contain up to 27 bytes, offering a data rate of 108.8 kilobits per second in each direction between the sensors/actuators and the local coordinator station, which could be a smartphone. If five-slot packets are used, they can carry 339 bytes in 3125 microseconds, which theoretically enhances the data rate to 433.9 kilobits per second. To get even better data rates, it is possible to use an asymmetric channel. However, accommodating for higher layer losses (loss of payload bytes due to additions from RFCOMM, L2CAP, and HCI layers) reduces the achievable data rate drastically. As a result of such overheads, applications that just want to connect, transfer data, and disconnect will spend substantial time inquiring, paging, performing service discovery, and configuring links before they can even begin using link bandwidth for data transfer.

Even if the L2CAP packet is split into two high rate DH1 packets with each pair of packets carrying 28 bytes the data rate on air is lowered to 112.2 kilobytes per second. When split across 24 channels, this data rate would dwindle down to 4.7 kbps and would be insufficient for a 24-channel IoT-HSN, going by the QoS indicated in

Table 1. Bitrate QoS requirements for top Internet of Things (IoT)- healthcare sensor network (HSN) parameters.

S. No	IoT-HSN Parameter/Control	Bit Rate
1	Drug delivery	16 kbps
2	Electroencephalogram (EEG)	86.4 kbps
3	Electrocardiogram (ECG)	192 kbps
4	Deep brain stimulation	320 kbps
5	Electromyogram (EMG)	1.563 Mbps

. We should also remember that this is the maximum calculated data rate over air. This data rate would reduce while crossing the tissue interface due to body mass and fluids. While any protocols including Bluetooth could end up facing this limitation, Bluetooth would certainly suffer more being low in bandwidth to start with.

As Bluetooth would not be satisfactory for multi-channel IoT-HSN applications, we next examine standard industrial control protocols for suitability.

2.3.3. Evaluating Industrial Process Control Protocols for IoT-HSN Applications

The process control industry uses smart control equipment with in-built diagnostics that offer an enhanced understanding of the process at reduced engineering costs, and without any safety concerns. Industrial WSNs can outperform traditional, wired process control networks by running at higher data transmission speeds. HART (Highway Addressable Remote Transducer) is a popular control protocol with a data rate of 1.2 kbps, the FF (foundation fieldbus) runs at 31.25 kbps [22] and WirelessHART (based on the IEEE 802.15.4 standard [23]) tops the chart with 250 kbps with all the data accessible by mobile users too [24].

Moreover, devices in wired control systems share a single bus, while multiple wireless communications can act simultaneously if there is no mutual radio interference, as put forth by Song et al. [25]. Also, more wireless sensors/data-points can be used for a better performance.

The reliability of WSNs can be increased by redundancy in equipment and communication channels. Faulty sensors can also be detected and replaced as pointed out by Banerjee et al. [26].

2.3.4. Wireless Industrial Applications

Working examples of wireless in control include a self-organizing mesh field network used to monitor wellhead annular pressure and heat exchanger pressures on an offshore platform [27].

Temperature monitoring on a rotating drier to ensure that the proper temperature is reached and maintained during the drying process [28] is another application where wiring costs are prohibitive and wireless temperature sensors are appropriate.

2.4. HART and WirelessHART

WirelessHART (Highway Addressable Remote Transducer) is one such open-standard wireless networking technology for process automation [24]. Another such open-standard wireless technology was developed by ISA, the ISA100.11a [29].

The HART protocol standard for wired, smart instrument-based process-control in the industry has ensured that devices from multiple suppliers work together since the late eighties. The population of HART devices in use is close to 50 million in the world today, totaling up to 75% population of all smart devices deployed. WirelessHART is getting robust and secure and is being tested in IoT applications other than HSN. This is the main reason behind our choice of WirelessHART as the protocol for this evaluation.

2.4.1. WirelessHART Protocol

The HART Field Communications Protocol standard [22] allows piggybacking of two-way communications on a 4–20 mA standard instrumentation signal while not interfering with the integrity of sensed values.

The current version HART 7 includes a new WirelessHART communication protocol [24] that targets fixed biosensors, bioactuators, and rotating equipment and has wireless mesh capability with time sync, along with transport and network layers. In addition, the WirelessHART standard leverages other existing standards such as the IEEE-802.15.4 standard [30], AES-128 encryption [31], and DDL/EDDL [32]. The WirelessHART standard provides a 128-bit AES encrypted secure networking technology operating in the 2.4 GHz ISM radio band. It utilizes IEEE 802.15.4 compatible DSSS radios with packet by packet channel hopping [33] for improving reliability and avoiding interference from metallic plant equipment. It supports high speed piped data communication, block transfers, security with encryption/decryption, event notifications, and advanced diagnostics with very good dynamic performance. The biggest advantage of WirelessHART is that it relieves a user from the tedious manual labor-intensive tasks involved in laying, documentation, and maintaining wiring cables.

WirelessHART devices can be easily scaled up at low cost or seamlessly integrated in no time with a HART wired network due to backward compatibility. WirelessHART mesh is a flexible, adaptive network with self-organizing and self-healing capabilities that can coexist with other wireless networks without issues. It monitors any degradation of communication links and keeps mending and adapting the network for optimal performance. It determines alternative routes around obstacles and keeps hopping channels for routing.

Use of WirelessHART links would help with better management of remote plant areas. Additional diagnostics smoothen out troubleshooting and maintenance of instrumentation loops. Supervisory compliance monitoring in environmental, safety, and health would benefit highly from the use of WirelessHART.

2.4.2. WirelessHART Industrial Applications

IoT-HSN control applications could possibly use WirelessHART just like an industrial control application does. WirelessHART has an optimal data rate of 250 kbps for handling the relay of both sensor and control data safely. The control design can be redundant to improve the reliability of control.

Figure 1 shows that modeling an industrial control system using WirelessHART is trivial, but we will try to evaluate if WirelessHART could work for an IoT-HSN working on 802.15.6 protocol for possible HSN control applications.

3. WirelessHART-Based Framework for Control in IoT-HSN: The 24-Channel Model

We designed a cellphone-based coordinating sink station (CSS) that could serve as the gateway node for physiological instrumentation and control. We also designed and created a data acquisition system for the IoT-HSN using the CSS. If the feasibility of WirelessHART for our 24-channel IoT-HSN model and IoT-HSN control framework on 802.15.6 protocol could be tested, we could use the same CSS for control applications. To check for feasibility we wrote a simulation in MATLAB [34]. The 24 channels could be utilized by biosensors and bioactuators in any share ratio. The performance parameters (about Supplementary Materials) could apply equally for either case as the protocol would be equally applicable to both.

Framework for the 24-Channel IoT-HSN Model

The QoS obligations for the throughputs for top IoT-HSN applications as specified by IEEE 802.15.6 standards are shown in Table 1.

For the five parameters, the latency requirements were less than 250 mS. The latency requirements for the 24 parameters in our IoT-HSN would be met when three channels were available. This assertion is based on the amount of bandwidth available uniformly across the working channels. No throttling of sample rate would be required, and samples could be transmitted at higher than the minimum Nyquist rate for a WirelessHART implementation except for the EMG application. To satisfy the bitrate required for EMG, we could reduce the sample rate or resort to delta modulation for lowering the data size.

Thus far, no protocol that can manage control has been suggested for 802.15.6 IoT-HSN standards. There are no known simulators that would let us model the control for an IoT-HSN system based on the 802.15.6 stack. We had to create our simulation using 802.15.4 radio using the same spectrum in the 2.4 GHz unlicensed band. WirelessHART protocol works fine and robustly in this band.

We modeled an IEEE 802.15.4 Wireless based IoT-HSN instrumentation and control schematic to run in the CSS, and interface with IoT-HSN bioactuators using WirelessHART. We had to restrict the signal power within the IoT-HSN based on the signal strengths for the different physiological parameters. The 24 channels were used to mimic relaying of physiological parameters from the subject’s head, heart, internal organs, and limbs. No human subjects were directly involved as the data was obtained from the public research database Physionet [35]. Although the model used 24 parameters, it functioned using 15 channels (Channels 11–25) offered in WirelessHART.

Table 2. Channels in the IoT-HSN model (* marks the actuators). Abbreviations: BPM, Beats Per Minute; PAP, Pulmonary Artery Pressure; CVP: Central Venous Pressure.

Channel	Parameter	Channel	Parameter
1	EEG-Parietal (μV)	13	Thoracic Resistance (V)
2	EEG-Occipital (μV)	14	Abdominal Resistance (V)
3	Respiratory Airflow (V)	15	Blood Pressure (mmHg)
4	Electroculography (L)	16	Body Temperature (Deg F)
5	Electroculography (R)	17	Blood Sugar (mg/dL)
6	Oxygen Saturation (%)	18	Insulin Level (pmol/L)
7	Heart Rate (BPM)	19	Insulin Injector * (syringe unit)
8	Pacemaker Diagnostics * (Data)	20	Urine Creatinine (g/dL)
9	ECG (mV)	21	Nerve Conduction Test (ft/s)
10	PAP (mmHg)	22	Musculature Actuator * (μV)
11	CVP (mmHg)	23	EMG1 (μV)
12	Respiration Rate (/min)	24	EMG2 (μV)

provides the channel details for the modeled HSN.

Three of the 24 channels, channels 8, 19, and 22, were configured as bioactuators and the rest of the channels were used by sensors. The biosensors and bioactuators communicate via an ad hoc link to the coordinating sink station that has an ad hoc link to the body area network (BAN) gateway. The gateway connects the biosensors to their specific IoT-HSN base station in the network. The below figures show the test on the working of these 24 channel networks. For this research work we did not focus extensively on the network performance of the IoT-HSN, however, the basic performance results are discussed for each of the scenarios.

Figure 2 shows a basic and simple scenario 1 with a single 24-channel IoT-HSN communicating with its base station, which is wired node 27 in the figure. The channels in the IoT-HSN connect to the BAN gateway using 802.15.4 ad hoc links. The data is then relayed through a router to the base station. Multiple hour-long simulations were run for this scenario and the second scenario described subsequently.

Table 3. Model configuration for the 24-channel IoT-HSN. Abbreviations: SDN, Software-Defined Networking; UDP, User Datagram Protocol; BE, Bit Errors; OQPSK, Offset Quadrature Phase-Shift Keying.

Sensor Setup		Ad Hoc Link	Application
Mobility/Power	Air Interface
Mobility model—none	Protocol—Zigbee	Point to multipoint	Distribution—Constant
SDN controller—enabled	Frequency—2.4 GHz	Wireless	No encryption
Transport—UDP	Data rate—250 kbps	No pathloss	QoS—BE
Power—battery+harvest	Modulation—OQPSK	Half duplex	Method—Unicast

shows the other parameters of the network configuration.

Figure 3 shows scenario 2 with multiple 24-channel IoT-HSNs in the vicinity of each other for interference studies. In this scenario, four IoT-HSNs each with 24 channels try to communicate to their respective base stations through the same BAN gateway using 802.15.4 ad hoc links. The IoT-HSN labeled P2 sends its data to another wired base station on the same subnet. The IoT-HSN labeled P3 tries to transmit its data to its base station in a different subnet connected through a second router. The base station for the fourth IoT-HSN labeled P4 is a wireless node connected to the wired network through an access point running standard wired Ethernet on the wired interface and IEEE802.11b/e on the wireless interface. Two-way communication applications were set up between the bioactuators and their respective base stations. The base stations gather data from these channels as well as provide this with commands for bioactuation. As human subjects have varying sizes, the placement distance of the biosensors for parameters has been kept different for the four IoT-HSNs.

This scenario was modeled to add more constraints on performance through an increase in the number of sensors in the same vicinity to study the effects of interference, single BAN gateway for multiple IoT-HSNs, low buffer sizes, and the use of wired and wireless links to base stations beyond the BAN gateway. The network parameters are the same for scenario 1 as indicated in Table 3. Figure 4 shows a capture of the simulation while running.

4. Results: Performance Evaluation and Feasibility Check

This section presents results obtained from the 24-channel IoT-HSN model. Some aspects of the design are focused in this section as they help explain the results better.

4.1. Raw Channel Performance without Optimization

In the scenario shown in Figure 2, the unoptimized throughput achieved is 56.2 kbps which is way more than enough to support the data traffic between the IoT-HSN and the base station. This is a simple scenario with just one IoT-HSN communicating with the BAN gateway. There are no severe constraints on the resources except for the 24 parallel applications on the 24 channels.

Table 4. Summary of relevant results with average values from scenario 1 simulation.

Head	Value	Head	Value
Packets generated	9.36 M	Delay/channel	46,694 μs
Payload (bytes)	468 M	Average jitter/channel	21,546 μs

summarizes the results from the model after averaging hour-long simulations.

The scenario modeled in Figure 3 and Figure 4 has a lower unoptimized throughput of 8.9 kbps reported by the simulation with one channel, which is slightly lower than the maximum bandwidth as indicated in

Table 5. Summary of relevant results with average values from scenario 2 simulation.

Head	Value	Head	Value
Packets generated	39.24 M	Delay/channel	86,530 μs
Payload (bytes)	1962 M	Average jitter/channel	25,836 μs

. This bandwidth is achieved after the effects of interference, multiple subnets, and a second wireless network. The bandwidth is still enough for supporting the four networks in the scenario, as will be inferred from the discussion in Section 4.2 after optimizing the transmission of samples by cutting down the transmission rate. With further optimization and relaxation on constraints, better performance is expected from the network. Table 5 summarizes the results from the model for this scenario.

4.2. Channel Performance with Sample Cut

The HART protocol was developed on the 802.15.4 wireless protocol and used a peak bandwidth of 250 kBps for the communication of sensor and bioactuator control data. The HART frame permits one message/packet of 127 bytes to be transmitted every 10 ms. A transmission bandwidth of 12.7 kBps is required for such a rate of packet generation. The specification stipulates for eight measurements per packet, each measurement data spanning 2 to 4 bytes plus an extra overhead of 5 bytes, which require 21 to 37 bytes.

Table 6. Bandwidth (BW) and payload for the IoT-HSN model.

Good/Active Channels	Max BW in kBps Realized	Number of 2 to 4 Byte Samples in Payload in 10 ms
1	12.7	8
2	25.4	16
3	38.1	24
4	50.8	32
5	63.5	40
6	76.2	48
7	88.9	56
8	101.6	64
9	114.3	72
10	127	80
11	139.7	88
12	152.4	96
13	165.1	104
14	177.8	112
15	190.5	120

shows our results with 4-byte encoding of all data samples in the model.

The results indicated that a single active channel permitted eight parameters at a frequency of 100 samples per second to be transmitted. This rate of sampling was perfect for the IoT-HSN model for energy saving using sample reduction with 1/3 to 1/4 of samples eliminated for an approximation [36]. Our IoT-HSN used 24 parameters requiring at least three channels to be active at a time for cooperative transmission at the rate of 100 samples per second.

We kept adding the number of active channels one at a time, with the assumption that the distribution of resources was equal between the data parameters. Also, for simplicity, we assumed that all parameters had the same sample rate and were being actively transmitted concurrently. When probing up to three active channels, fulfilling the QoS requirements for parameters was not possible due to a minimal and inadequate sample rate. Nonetheless, when we made the fourth channel available, the issue was resolved, and a sample rate of 133.33 samples/s was attained for the 24 IoT-HSN parameters. This rate was better than what was required for the approximation with a third of the total samples discounted from transmission [36].

After adding and activating the 11th channel, a transmission rate of 8800 samples/s was achieved, indicating the attainment of breakpoint for the 24 parameters containing IoT-HSN parameter and control data. Each parameter then transmitted at 360 samples/s. Hence, we could demonstrate that WirelessHART would undoubtedly work appropriately for IoT-HSN control applications on the QoS requirements and data rate front.

Next, we extended this work to differential sampling policies. When we used an analogous system from voice encoding and packed 1-bit delta modulation (DM) encoded 12-bit signals in these packets we found out that 2 bytes could hold 16 samples, 3 bytes could hold 24, and 4 bytes could hold 32 samples. For the 1-bit DM case even in the face of random channel failures, we found out that parameter and control data transmission could work optimally even if up to four channels were blacklisted at some time.

With 1-bit DM, 16 samples to 32 samples per packet were transmitted. The ensuing error due to approximation was elevated, but the capacity enhancement achieved was 16 to 32 times. The scheme allowed for the transmission of 25,600 samples for eight parameters which is overkill. The rate was still higher than 1000 samples/s for all the 24 IoT-HSN parameters, the model performance was enough for 24 physiological parameters with just one working channel. Each of the channels, if we tried squeezing the data from all 24 IoT-HSN parameters into the eight allowed channels, each channel could handle a packing up of 1066.67 samples. Figure 5 shows a comparison of the original data from the pulmonary artery pressure biosensor using one of the 24 IoT-HSN channels to its reduced sample DM encoded signal. Figure 6 shows a comparison of the cardiovascular pressure biosensor using another of the 24 channels. The figures show optimized encoding after multiple runs and display just one cycle of the waveform while the actual data includes several cycles of data for the human subject.

Using 2-bit adaptive delta modulation (ADM) we were able to attain almost half of these result figures, but the tradeoff was improved accuracy. When we extended the model to a higher accuracy 3-bit ADM system, it was just perfect for 360 samples/s system. This scheme would also work flawlessly to satisfy the QoS requirements for our IoT-HSN model. Figure 7 shows the ADM encoding on the pulmonary artery pressure signal data and Figure 8 displays the encoding for the cardiovascular pressure signal data.

The details of the two parameters and mean square errors (MSEs) for DM and ADM are shown in

Table 7. Signal details and error performance for DM and ADM in the two channels. MSE: mean square error.

S. No.	IoT-HSN Parameter	Sample Size	Signal Excursion		Delta	MSE(DM)	MSE(ADM)
			Rmin	Rmax
1	Pulmonary artery pressure	256	21.4119	43.3432	0.9	2.7508	1.0381
2	Cardiovascular pressure	256	–2.1515	5.6229	0.4	0.2472	0.2009

. As expected, the MSE decreases in case of ADM encoding for both the channels as compared to DM.

4.3. Assessment of Bit Error Rate (BER) Confidence Level for WirelessHART Channel for the Model

While receiving data on the WirelessHART network, the value of the true BER is not crucial. The threshold value of the BER is critical, and an adequate volume of data needs to be received for obtaining the confidence about maintaining the system BER below the threshold. It is essential to focus on the number of errors E that result on repeated transmission of N bits to get the overall percentage of tests for which the achieved BER (E/N) remains under the threshold. The BER confidence level in percentage can be thus known. It can be found out using Equation (1) for a Poisson distribution of errors and signifies the percent confidence about the WirelessHART network’s BER being lower than the stipulated threshold, infinite repeats of transmission with the BER noted.

$$CL=1-e^{-N.BERs}{\displaystyle \sum }_{k=0}^{E}e\frac{{\left(N.BERs\right)}^k}{k!}$$

(1)

The observed confidence level is always under 100% as quantifying for an endless timeframe is infeasible. It is essential to discern an objective level of confidence before starting a BER evaluation. Targets may on average be at higher than 80% confidence level, with 93%–95% as the best level figures achieved.

BER Confidence Level for WirelessHART Model Tested

WirelessHART specifications have stringent BER requirements in the range of one bit of error per 1000 received packets or messages, with maximum message or packet size of 127 bytes.

To indicate the performance of our IoT-HSN model, we determined the amount of time required to measure the BER for reaching a confidence level with the exact number of bit errors in question. We studied the BER confidence level in our model and observed it for limiting data rates of 31.5 kBps and 55.5 kBps and up to two-bit errors for which the outcomes are presented in

Table 8. BER measurement and confidence evaluation with changes in time window.

#Bit Errors	0	1	2
Measurement Time (s)	BER Confidence Level (CL × 100%)
3	73.61	Very low	Very low
4	83.07	Very low	Very low
5	89.14	Very low	Very low
6	93.03	74.47	Very low
7	95.53	81.64	Very low
8	97.13	86.95	Very low
9	98.16	90.81	Very low
10	98.82	93.58	81.96
11	99.15	95.66	86.5
12	99.63	97.96	90.03
15	99.87	99.01	96.18

and Figure 9. The findings report the time needed to reach a desired confidence level for the limiting data rates. The QoS requirements in most communication standards stipulate values with a confidence level below 75% as not acceptable. We disregarded any values below this threshold.

4.4. Delay and Throughput

We also attempted to check the working of our 24-parameter IoT-HSN model with regards to the transmission latency and the maximum throughput over some transmission channels.

The IEEE 802.15.6 standard offers seven available bands of which we selected two at extreme ends of the spectrum (420–450 MHz band and 2400–2483.5 MHz). The bands had adequate bandwidths for 15 channels. The first band offers greater communication distance over a restricted number of channels. It could be used for transmission of data from the IoT-HSN coordinator unit to the base station due to its bigger transmission range. Using lower frequencies of operation, this band is expected to have a lower transmission error rate, and we evaluated the band for zero error performance.

The 2400–2483.5 MHz band is common between 802.15.4 and 802.15.6 protocol families and the wider of the two. It can accommodate more channels for a shorter communication range. This band would be appropriate for ‘biosensor to biosensor’ and ‘biosensor to CSS’ communication and hence could support transmission of biosensor and control data for an IoT-HSN with control scheme. The band offers four data rates ranging from 121.4 kbps to 600.4 kbps that could be chosen depending on the specific IoT-HSN application. We probed the data rates while permitting transmission errors.

The results related to the end to end delay in packet transmission are in Figure 10 for payload variations up to 250 bytes for the two channels. The peak throughput obtained for the same packet or payload sizes is shown in Figure 11. Realizable transmission data rates over the 420–450 MHz channel were the same as that for the ideal channel. However, the throughput was significantly lesser than the theoretical peak value for the four data rates due to the bit errors allowed in our model.

5. Conclusions and Discussion

The peak data rates for the 2400–2483.5 MHz band were in the range 600 kbps which is more than enough for most physiological parameters. For the others, approximation through compression could meet the capacity of the wireless resources according to the 802.15.6 protocol. The distance of communication is a challenging issue because RF dissipates very quickly in tissue and bone [11]. The approach used in Reference [11] uses low MHz frequency in the Medical Implant Communication System (MICS) 402–405 MHz band, suggesting the use of lower channels. We investigated the 420–450 MHz range and observed that it could provide the best compromise due to limitations of RF due to dissipation in tissue while it would suffer from some attenuation. If the maximum effective isotropic radiated power (EIRP) of wireless transmitters is kept under 25 μW, with a current consumption of less than 6 mA during the communication session, the channel would still meet the requirements with data compression evaluated in Section 4.2. The work by Poon et al. [37] shows that for small transmitter–receiver separations across the air–tissue interface, the optimum frequency is in the GHz range indicating that higher channels in WirelessHART can still be used in an HSN. The QoS figures were also at an acceptable level of confidence allowing some errors in transmission.

The results in Table 4 and Figure 6 confirm that the time window for measurement must be enlarged for an adequate level of confidence if the bit errors are growing for the model. The results from the model indicate that wireless control for IoT-HSNs would work well on WirelessHART protocol and would also meet the QoS requirements related to sampling and rate of error on noisy channels or with mobility.

The results in Figure 6 and Figure 7 reflect that with a payload of 127 bytes, which is typically used by WirelessHART, a maximum throughput of 332.3747 kbps is still attainable for an IoT-HSN implementation with transmission errors permitted. Except for HSN applications such as EMG that demand high rate of transmission, other IoT-HSN applications using biosensor and bioactuator data encoded in 12-bits would work perfectly fine with our proposed setup.

The results indicate that WirelessHART fits the requirements on the number of channels and their performance, channel bandwidth required for IoT-HSN applications, QoS for healthcare as laid down in IEEE 802.15.6, payload and throughput required for one or more coexisting 24-channel IoT-HSNs even under possibility of interference, transmission delay thresholds, and allowable errors when used for sensing as well as control applications in IoT-HSNs. This work opens doors for further probing of WirelessHART for robustness and applicability on aspects involving control and micro-hardware for wearables and implantable biosensors/ bioactuators. WirelessHART offers a promising possibility to be chosen as a standard for IoT-HSN control applications while none exists currently.

While the basic parameters of the network look good for utilizing WirelessHART for control in IoT-HSN applications, the dynamic performance of the protocol needs to be scrutinized in greater detail for HSN control applications. An extension of this work could target a clinical setup involving a variety of physiological parameters that depend on sensor values varying at a slow rate and contrast it with the ones with a fast rate of change. Looking further, requirements for possible control applications in well-established and robust use cases such as pacemakers, insulin injectors, and movement bioactuators could be probed for the model.