Determination of the Ideal Protocol Stack for the Transmission of Health Data over 6LoWPAN IoT Networks

It is expected that almost every day electronic devices will be connected to the existing internet infrastructure in the context of Internet of Things (IoT). These devices will enable to sense and actuate the physical world. It is foreseen that miniaturized e-health devices will enable monitoring vital health of patients. There exist some studies on networking these e-health devices within the Internet. In this realm, several network protocols are being standardized. 6LoWPAN of IETF is one of these efforts where some set of protocols can be stacked over IEEE 802.15.4 radio. However, it is not clear that which ideal protocol stack for transmission of health data can be adopted well. The novelty of this work is that we studied determination of ideal protocol stack for transmitting health data over 6LoWPAN IoT networks. So then, we carried extensive simulations over Cooja simulator. The compelling results are presented in this work. The results show that 6LoWPAN IoT health networks can be used to serve vital health data of patients.


I. INTRODUCTION
ANY of the current everyday electronic devices in use are able to exchange data autonomously. These devices can network among themselves as well as connect to an existing Internet network. The concept of the Internet of Things is the general name given to this structure [1], [2]. Devices within this scope are mostly low-cost and limited devices. IoT devices generally obtain data from their surroundings with the help of sensors on them. These devices send the data they receive to a center for processing or perform some other operations. Connecting each of these devices directly to the Internet will incur additional costs. To avoid this, generally, IoT devices primarily form a network within themselves. A gateway node within the scope of this network acts as a bridge between the Internet and the IoT network.
The IoT concept is currently used in smart home/office systems, factory production lines, smart agricultural systems, smart city/traffic systems. In the future, it is envisaged that IoT systems will become more widespread and expand into more areas. The lightweight and portable IoT devices has being introduced IoT concept into the healthcare sector. Especially for health monitoring, their portability and lowpower features have made IoT devices the preferred choice.
Although the IoT concept is currently in use in many areas, it is still a developing technology. Therefore, there are no emerged de facto standards yet. Although wireless technologies such as Wi-Fi, Bluetooth and GSM can also be used for the IoT environment, the power saving offered by 802.15.4 wireless technology is more suitable and common for IoT systems. For energy-saving IoT devices, hardware is also constrained to keep the energy consumption low. Therefore, instead of protocols with high system requirements, lightweight protocols are being proposed and standardized. One of these efforts is 6LoWPAN working group of IETF. 6LoWPAN seems like providing promising IoT network standards and protocols [3].
Typical 6LoWPAN standard network layers and protocols of IoT devices is given in Hata! Başvuru kaynağı bulunamadı.. In this layered structure, the protocols in the transport, network and application layers are almost standardized and widely used. However, the protocols used in the data link layer needs to be selected according to application quality of service (QoS) requirements. Therefore, selection of ideal protocol stack for applications requires careful research.
In this work, careful determination of the ideal protocol stack for e-Health application is investigated. As is known, e-Health applications are sensitive to delays. Therefore, timely transmission and hand off e-Health data to a distant center are core QoS requirements of e-Health applications. Besides, an e-Health application may need different health sensors such as ECG, EMG, Blood Pressure, Body Temperature and Body Position etc. Each health sensor requires different maximum delay thresholds. This can vary from seconds to hours. Moreover, maximum delay thresholds may also vary for different patient categories such as critical, non-critical and follow-up patients. Thus, to achieve this, we investigated the performance of different protocol stack of MAC and RDC Determination of the Ideal Protocol Stack for the Transmission of Health Data over 6LoWPAN IoT Networks S. BİLGİLİ and A. K. DEMİR  T layer of an e-Health application for different patient categories so that patient's vital health data can be monitored smoothly.
Transmission of e-Health data over IoT networks is fairly a new research subject. Thus, there does not exist satisfying results in the literature and applications. The novelty of this work is that e-Health data is transmitted with standard CoAP application layer protocol and the effect of performance belonging to MAC and RDC layer protocols, such as CSMA and contikiMAC, are explored with simulation of real network and hardware. Furthermore, the network topology and the number of patients (clients) equipped with e-Health sensors are varied with extensive simulations. This paper is organized as follows: In section II we surveyed related works that are associated to subject of this paper. Our methods are provided in section III. Based on these methods, we investigated results in section IV. In section V, we provided conclusion and future work.

II. RELATED WORK
The transmission and processing of vital health data in IoT environments are emerging research subject that is being explored scarcely yet. The IoT for healthcare is broadly surveyed in [4], [5]. However, there does not exist a comprehensive survey of transmitting health data in 6LoWPAN IoT networks. Moreover, there does not exist concrete study on transmitting health data in 6LoWPAN IoT networks. We briefly talk about networking health data over 6LoWPAN IoT networks in this section.
Sphere framework [6] brings 6LoWPAN IoT standards for healthcare to the home. The initial outcomes exhibit good 6LoWPAN network performance to carry out healthcare data (99.97 percent average PDR).
IoT net platform [7] anticipates technological solutions for healthcare protection and services through trendy 6LoWPAN IoT networks. In [8], again, analysis of 6LoWPAN IoT network is provided for maternal healthcare. It is concluded that both CoAP and 6LoWPAN could be applied for healthcare monitoring. The research in [9] demonstrates that 6LoWPAN IoT network is able to be used for healthcare services with CoAP.
The initial research views that 6LoWPAN IoT networks are promising solution to be used in healthcare applications. However, as it is seen that the usage of 6LoWPAN IoT networks in healthcare domain is an unexplored area. We extend this gap furtherly in this work.

III. METHODOLOGY
Within the scope of this section, we present the methodology of our work to transmit vital health data over a 6LoWPAN IoT network. The details are as follows:

A. Obtaining Health Data
Although performance evaluations of this work is executed on a simulation environment, real world health data is required to get realistic results. To achieve this, MySignals health sensor kit is used with various additional hardware, Arduino Uno microcontroller and Raspberry Pi microcomputer as seen in Fig. 1. MySignals health sensor kit is programmed with a simple firmware to get all sensor data. Various sensor data is collected from various persons to ensure collected data is realistic.

B. Health Data Traffic Characteristics
Right after obtaining real-world health data, each sensor data is composed into a packet. Each health data is encapsulated into 64-byte packet. Each packet contains data from all available health sensors. Sensor data types and their length is given in Table I. In this work, although we used all available health sensors, there's 20 bytes free space in packet which can be used for patient information or extra sensors. These eHealth data packets are updated in memory dynamically every 300ms. The clients send CoAP CON messages to obtain eHealth data. Respectively, the server nodes send piggybacked CoAP ACK messages that contain eHealth data whenever they receive a CoAP CON message.

C. Latency QoS Requirement of Health Data
We envisioned that each eHealth sensor data needs to be transmitted within a maximum latency deadline. Thus, we talked a couple of medical doctors to detect latency deadline of eHealth data. According to interviewed medical doctors, patients should be divided into three groups, critical, noncritical and follow-up patients, as they may have need different latency deadlines. As a result, maximum latency deadline values are given in Table II. These values represent the maximum latency tolerance of eHealth data generated by health sensors. For example, a critical patient's consecutive ECG sensor data needs to be transmitted within 1 minute. On the other hand, ECG sensor data demand maximum 60 minutes latency for non-critical and follow-up patients. Moreover, body position data requires maximum 30 minutes latency for critical and non-critical patients.

D. Simulation Environment
We used Cooja [10] network simulator that simulates multiple types of nodes and network software running on nodes. Cooja simulator mimics ContikiOS [11] operating system designed for IoT devices. Also, Cooja network simulator offers multiple measurement tools. WisMote is used as a hardware server and gateway node in simulations within IoT network. These server nodes generate sampled eHealth data traffic. Californium [12] is used as CoAP client running on real PC hardware and requiring eHealth data piggybacked in CoAP ACK messages. In other words, CoAP servers, running on simulated IoT network, are programmed with Erbium [13] implementation of CoAP, and CoAP clients, running on real PC, are programmed with Californium implementation of CoAP. The simulated IoT network topology is given in Fig. 2. The distance between each node is about 40 meters. This enabled us to simulate 12 different scenarios (2x2x3). The number of clients is varied from 2 to 30 stepped by 2 (2,4,6,..,30). The number of servers is always the same as the number of clients. The positions of servers are detected according to their relative position to the gateway node. Always, the closest nodes are selected as a server. Each client sends totally 100 CoAP CON requests. Each server replies with CoAP ACK message as soon as it gets CoAP CON request. The total elapsed time is to transmit 100 CoAP CON messages. According to CoAP standard, the default maximum re-transmission of lost CoAP CON packets is 4 times. One thing to keep in mind is that CoAP handles a default congestion control mechanism.

E. Performance Metrics
To inspect how well health data is transmitted in an IoT network, we need some measurable performance metrics. In this sense, we identified 3 different performance metrics, latency, energy efficiency and reliability. We give the definition of each performance metric below.

1) Latency
Latency metric defines the time elapsed between two consecutive CoAP ACK messages. As the subject of this work is health data, it means that the data must be transmitted within deadline time limits. These time limits are shown in Table II.

2) Energy Efficiency
Energy efficiency metric is used to represents the amount of energy consumed by a server node. This metric is calculated as the average of consumed energy of all server nodes. Indirectly, this metric shows the overall network life time.

3) Reliability
Reliability metric demonstrates the percentage of successfully received CoAP ACK messages. Higher reliability means that eHealth data is smoothly displayed at health center. The low reliability may result with low perceived health data.

IV. PERFORMANCE EVALUATION
In this section, we investigate the performance of 12 scenarios, given at Section III.D based on 3 different performance metrics.

A. Latency Evaluation
As stated earlier, health data should be transmitted within a certain period of time. Time limits for different health sensors and patient groups are shown in Table II. The graphs in this section shows the performance indicators as well as the latency deadline indicators. Thus, it is possible to determine how many clients can be supported by the specified latency deadline in a given protocol stack. Please note that if there's no latency deadline indicator for a performance indicator, it means that all results in the graph comply with absent latency deadline.
Various simulations were performed for different protocol stacks. Fig. 3 shows the latency graph with protocol stack of nullMAC and nullRDC in MAC and RDC layers respectively. As can be seen in the graph, all results are lower than deadline of 30 and 60 minutes (Hence, these deadline indicators are not shown in the graphs). All number of clients, other than 26 and 30, comply with deadline limit of 15 minutes. Therefore, the network can support up to 24 clients. For example, body temperature sensor data can be used safely for all patient groups up to 24 patients. However, for more critical data with deadline limit of 1 minute, only 8 clients can be serviced when PDR equals to 100. Fig. 4 shows latency graph of CSMA and nullRDC protocols. As it is seen, deadline limits of 15, 30 and 60 minutes are missing in the graph because all latency values are lower than 15, 30 and 60 minutes. Therefore, only 1 minute latency indicator is given in the graph. For all PDR values, up to 16 clients can be monitored without any trouble. However, for example, when the client number is above 20 the network is not able to support health data with 1 minute latency deadline.
In Fig. 5, nullMAC and contikiMAC combinations are used for latency deadlines. Accordingly, for 30 minute latency, only up to 18 clients can be handled. Besides, for 15 minute latency, individually up to 8 clients can be supported. Nevertheless, for 1 minute latency, only 2 clients with PDR values 100, can be serviced. CSMA and contikiMAC protocol combination latency graph which is given in Fig. 6 shows that 24 clients can be monitored for latency deadline of 30 minutes. Based on the figure, for latency deadline of 15 minutes, there can be only 16 clients. More drastically, latency deadline of 1 minute can only support 4 clients.

B. Energy Efficiency Evaluation
In this section, we investigate the energy efficiency of MAC and RDC layer protocol combinations. Fig. 7 shows the energy consumption comparison of 4 protocol combinations when the PDR value is 100. Apparently, when nullRDC is used, the energy consumption significantly increases. Because while using nullRDC, 802.15.4 radio does not sleep when it is idle. Thus, it uses more energy. In contrast, contikiMAC sleeps the radio while it's idle. The effect of this mechanism can also be observed in the graph. Using CSMA or nullMAC protocol with nullRDC has almost the same energy consumption. However, while using contikiMAC protocol, selecting CSMA protocol causes more energy consumption against selecting nullMAC protocol.
Energy consumption values while PDR value is 95 is given in Fig. 8. Again, selection of contikiMAC in RDC layer significantly decreases energy usage. The results show similar curve with previous graph. However, difference between nullMAC/nullRDC and CSMA/nullRDC combinations is much more distinctive when PDR is 95.
In Fig. 9, energy consumption values for PDR value 90 is presented. Based on the graph, again, it is clear that contikiMAC protocol provides more energy savings. As can be seen, for protocol combinations with nullRDC, energy consumption values get higher as the PDR value decreases. Reliability values when the PDR value is 100 is given in Fig. 10. That graph shows that CSMA and nullRDC protocol combination gives better results. Besides, nullMAC and nullRDC protocol combination has results that are close to CSMA and nullRDC protocol combination. However, nullMAC and contikiMAC protocol combination cannot sustain reliability as the client number increases. CSMA and contikiMAC protocol combination gives the worst reliability especially for high number of clients.
PDR value of 95 is given in Fig. 11. As the client number increases, the gap between nullMAC/nullRDC and CSMA/nullRDC protocol combinations increases. CSMA/nullRDC gives the best performance compared to other three combinations. The graph shows that using CSMA protocol is helpful as CSMA maintains reliability high.
When PDR value equals 90, the same reliability performance is observed. Results are presented in Fig. 12. Once more, absence of CSMA protocol in protocol stack causes lower reliability results. Using CSMA is superior than using nullMAC cause CSMA protocol successfully retransmits lost frames. Using CSMA protocol with contikiMAC protocol gives undesired results when the number of clients increases. This is due to the fact that contikiMAC protocol sleeps radio to save energy, so CSMA protocol must wait for these sleep intervals. In this work, we investigate determination of ideal protocol stack for transmission of health data over 6LoWPAN IoT networks. Our extensive work shows that 6LoWPAN IoT networks are able to transmit vital health data of patients up to a certain point. Latency, reliability and energy efficiency graphs are analysed to determine the maximum patient number that can be supported in a 6LoWPAN IoT network.
Ideal protocol combination may differ based on patient category and health sensor. Although nullRDC protocol in RDC layer seems to show better performance, it results with inefficient energy consumption. Therefore, choosing ideal protocol combination highly depends on latency, reliability and energy efficiency performance results. For instance, even if CSMA/nullRDC combination can support up to 16 patients for critical health data in 6LoWPAN IoT network, energy consumption significantly gets higher.
In future, the more extensive simulations can be carried out by varying IoT network topology and PDR values. Routing protocol, RPL (especially RPL Objective Functions), is not investigated in this work to expose its effect on the performance. Moreover, only CoAP is used as an application layer protocol as it is the only candidate for now in IETF. Other being standardized protocols, such as MQTT, can also be considered. The least but not the last, CoAP promotes other congestion control mechanisms, such as CoCoA. Using different congestion control mechanisms to determine ideal protocol stack can also be inspected.