Abstract
A long term healthcare monitoring system requires battery operated devices with low-power technologies. Researchers tried to adapt various short-range technologies for Wireless Body Area Networks (WBANs) in ubiquitous health monitoring. The classical Bluetooth is known for its greedy power consumption, IrDA and NFC require line-of-sight conditions, and ANT has weak coexistence features and interference issues. A typical choice remains ZigBee/6LoWPAN over IEEE 802.15.4 based solutions in WBANs because of their low-power consumption. However, the recently proposed Bluetooth Low Energy (BLE) announced more compelling features in various aspects. Only few studies have been published supporting these claims on BLE. In this paper, we present a BLE based remote healthcare monitoring platform and we study its compatibility for ECG monitoring. ECG data requires continuous and real-time transmissions, making it particularly challenging for resource constrained devices. In our system, a BLE112 module from Bluegiga and a BLE USB dongle are used for WBAN. The performance of the system is evaluated experimentally and the results showed good potential of this proposed BLE platform in meeting the main QoS requirements of medical applications in terms of throughput, end-to-end delay, and packet error rate, while staying energy efficient.
1. Introduction
Recent technological advances in instrumentation and telecommunication/networking engineering have revolutionized medical practices by leading to the next generation of ubiquitous healthcare (u-healthcare) in monitoring patient's health status in a convenient and nonintrusive way [1–3]. The design of Wireless Body Area Networks (WBANs) is considered the most challenging part of u-healthcare applications. Considerable efforts have been contributed to the development of WBANs in the last several years [4–8]. However, there are still open research challenges especially related to the specific requirements of WBANs that need to be considered in order to be implemented and deployed in an effective u-healthcare solution. WBANs are formed by several low-energy, wirelessly interconnected biomedical sensor devices used to capture and transmit various physiological parameters of the human body (e.g., temperature, heart rate, electroencephalography (EEG), electrocardiography (ECG), and blood pressure). When dealing with battery equipped wearable sensors for health monitoring, one needs to be cautious about the power consumption in order to increase the lifetime of sensors and thus allow long term patient monitoring. In particular, wireless ECG measurement is quite challenging, because it consists of continuous and real-time transmission of various electrical activities of the cardiovascular system.
Several short-range technologies such as classical Bluetooth, Bluetooth Low Energy (BLE), ZigBee/6LoWPAN over IEEE 802.15.4, IrDA, NFC, and ANT were initially proposed for Wireless Sensor Networks (WSNs) and adapted to the WBANs. The classical Bluetooth is known for its greedy power consumption as well as the constraints on the number of paired devices per master node (with a maximum of eight nodes). In addition, wake-up delays are typically around three seconds. IrDA and NFC require line-of-sight conditions along with a target within less than 1 m [9]. ANT has weak coexistence features and interference issues. The most suitable technologies remain ZigBee/6LoWPAN over IEEE 802.15.4 physical and DLL specifications and the recently proposed BLE technologies. The ZigBee/6LoWPAN over IEEE 802.15.4 standard is mostly deployed for WSNs [10–13] but also adapted in WBANs communications for its low-energy properties [14], while the recently developed BLE stack is gaining interest in research community in WBANs for its low-energy consumption as well.
Motivations. The ZigBee/6LoWPAN over IEEE 802.15.4 based solutions and BLE technologies offer similar features, namely, low-power, low latency, low duty cycle, and short-range communications. BLE is a complete new protocol stack different from the classical Bluetooth, using asynchronous client/server architecture, and is designed for low duty cycle. It is often assumed that BLE is less consuming than ZigBee/6LoWPAN over IEEE 802.15.4 and offers more compelling features; however, few studies have been yet published supporting these assumptions. Most of the comparative studies in the literature on BLE consider the specifications provided by the manufacturer [15, 16], while the proposed performance evaluations mostly consider WSNs, do not deal with medical data [17, 18], focus on the energy consumption aspect only [19], or study the feasibility of BLE in healthcare applications [20, 21]. It seems interesting to evaluate the BLE performance experimentally to demonstrate its capacity to deal with the specificity of medical data. Note that both BLE and the ZigBee/6LoWPAN over IEEE 802.15.4 technologies were designed mostly to deal with periodic data, that is, transmitting only occasionally small amounts of data. In the context of u-healthcare, we need higher data rate, while staying energy efficient. For instance, ECG data is continuous and it should be transmitted in real time. In such a context, our main motivation is to study experimentally the performance of the BLE based platform and its capacity to deal with u-healthcare monitoring (high amount of data, timely delivery, etc.).
Contributions. The main contributions of this paper are as follows: first, we extend the systematic comparison of the emerging technologies, introduced initially in [15] and completed in this paper to provide more specifications, especially for the technologies compatible with ZigBee/6LoWPAN over IEEE 802.15.4 standard (e.g., the CC2530 system-on-Chip (SoC) and CC2420 transceiver integrated with the MSP430 microprocessor). The emerging technologies were compared in this paper in order to provide comparison between the technical specifications and the experimental results obtained through implementations in real-world scenarios according to the maximum peak energy, application throughput, and latency. Their capacity to deal with u-healthcare requirements has been discussed as well. From the above study, the most suitable technologies in WBANs are proved to be the ZigBee/6LoWPAN over IEEE 802.15.4 and BLE stack based solutions. In our previous work [14], 6LoWPAN over IEEE 802.15.4 based solution has been experimentally studied. It was proved suitable to transmit easily most of the medical data (such as blood pressure, accelerometer, body temperature, respiration rate, and blood PH), while ECG data required significantly higher processing time and peak power consumption. To study ECG data transmission, we have proposed a BLE based platform in [21], which provides a feasibility study, but the performance was not evaluated experimentally. To complete these previous works, we propose in this paper a BLE technology based experimental platform for ECG data monitoring and its performance evaluation focused on the throughput, end-to-end delay, and packet error rate. The originality and novelty of the paper lies in proposing a BLE technology based platform for ECG data monitoring in WBANs and studying its capacity to meet specific requirements of the u-healthcare applications. In addition, we compare the experimental results with the specification from manufacturers to demonstrate their performance in real-world conditions.
The rest of the paper is organized as follows. Section 2 gives an overview of the hardware and network requirements for u-healthcare applications and presents a systematic comparison of the emerging technologies, considering peak power current, throughput, and latency. In Section 3, we compare in detail the ZigBee/6LoWPAN over IEEE 802.15.4 and BLE stack based solutions. In Section 4, the proposed experimental BLE based platform is presented. Section 5 gives a description of the experiment and its parameters, as well as the performance metrics considered, followed by the experimental results and comparative analysis. Finally, Section 6 concludes this paper and outlines future work directions.
2. Requirements for u-Healthcare Applications
A brief summary of the hardware and network requirements related to design of WBANs nodes is presented in Tables 1 and 2 [22, 23].
Hardware requirements for WBANs.
Network requirements for WBANs.
Numerous low-power wireless technologies such as BLE, ZigBee/6LoWPAN over IEEE 802.15.4, IrDA, NFC, and ANT are available in the market. In the literature, several studies cover the state of the art of current challenges facing these technologies when applied to u-healthcare systems [1, 7, 24, 25].
In the following sections, we provide a systematic comparison of emerging technologies oriented to the support of low-power and low-energy devices for u-healthcare applications. Three main performance metrics, namely, power consumption, throughput, and latency, will be considered.
For ZigBee/6LoWPAN over IEEE 802.15.4 standard, the considered two main technologies, namely, CC2530 system-on-chip (SoC) and CC2420 transceiver chip integrated with microcontroller MSP430 from Texas Instruments, are widely deployed in WSNs and WBANs. Their main difference is that the CC2420 module includes only the RF transceiver and does not provide a microprocessor, while CC2530 SoC is a “ready-to-use” module which is a complete system with microcontroller, transceiver, and antenna on a printed circuit board. CC2420 module is cheaper and enables the designer to choose any microprocessor but is mostly used with the microcontroller MSP430.
2.1. Peak Power Current
The peak power current determines whether a technology is operable using a coin cell or not. The most commonly used coin cell that exists in the market is the CR2302 by Texas Instruments which is capable of providing the peak current of 15 mA. Table 3 summarizes the peak currents of the emerging technologies.
Comparison of peak power requirements for various technologies.
As shown in Table 3, NFC is the worst in terms of maximum peak current followed by ZigBee/6LoWPAN over IEEE 802.15.4, while the other technologies have quite similar power consumption. Note that BLE and IrDA have the lowest peak current.
2.2. Throughput
The air data rate that is usually specified with the available technology is different from the actual throughput. Table 4 depicts the air data rate and throughput of each technology.
Comparison of air data rate and actual application throughput.
From Table 4, it is obvious that the best air data rate is offered by IrDA and NFC. However, their most important drawback is that they require line-of-sight scenarios. The application throughput is variable and mostly depends on the application environment and parameters. Most of the technologies have similar throughput; however, BLE and NFC look superior.
2.3. Latency
Latency can be defined as the difference between the time at which the data was sent and the time when it was received by the end user. Latency is a very critical issue for healthcare applications and must be inferior to 125 ms [22, 23]. A comparison of the latency for each of the above mentioned technologies is presented in Table 5.
Comparison on latency requirements of short-range technologies.
From the performance description in the literature presented in Tables 3–5, it seems that all presented technologies could be adequate to u-healthcare applications and meet the main WBAN requirements. However, IrDA and NFC have an important drawback; they require line-of-sight conditions along with a target within less than 1 m. This seems impractical in healthcare applications with moving patients; hence, both are eliminated.
The other technologies such as BLE, ANT, and ZigBee/6LoWPAN over IEEE 802.15.4 standard are considered suitable for sensor networks, since they possess many flexible parameters that can be adapted to suit many low-power applications. However, BLE and ZigBee/6LoWPAN provide better coexistence with other wireless standards (such as WiFi) in their vicinity than ANT. Because BLE uses frequency hopping (FHSS) and ZigBee uses Direct Sequence Spread Spectrum (DSSS), both of them are able to mitigate interferences, with nearby RF transmitters. ANT has weak coexistence features and interference issues due to its TDMA based channel access method that is characterized by very small time slots and monitors channel interference using a technique called adaptive isochronous networking. This scheme works well within ANT enabled network devices; however, it may bring about failure in the presence of other technologies. Nevertheless, frequency agility feature may help ANT devices to hop to a different carrier frequency which can reduce interference.
From the above prior art study, it appears that the most suitable technologies for u-healthcare applications are BLE and ZigBee/6LoWPAN over IEEE 802.15.4. In particular, the 6LoWPAN over IEEE 802.15.4 based solution seems interesting because it allows interoperability to Internet of Things (IoT) through IPv6. Among the technologies compliant with 6LoWPAN over IEEE 802.15.4, the CC2420 transceiver chip with microcontroller MSP430 provides less peak power consumption than the CC2530 SoC, while offering similar throughput and latency. In the rest of the paper, we will focus only on BLE and 6LoWPAN over IEEE 802.15.4 based solutions.
3. Comparison between BLE and 6LoWPAN over IEEE 802.15.4
Both BLE and 6LoWPAN over IEEE 802.15.4 are strong competitor technologies. Although 6LoWPAN over IEEE 802.15.4 has been widely tested in various projects, BLE announced more compelling features in some aspects. Also, the 6LoWPAN working group is considering a draft regarding the specification for the transmission of IPv6 packets over BLE [34]. A brief comparison of BLE and 6LoWPAN over IEEE 802.15.4 is shown in Table 6.
Comparison of BLE and 6LoWPAN over IEEE 802.15.4.
In several previous works, a complete u-healthcare system based on 6LoWPAN over IEEE 802.15.4 has been developed to send ECG signals at different rates using an ECG simulator [14, 21, 35]. The presented systems were able to sample the simulator data from the sensor node and forward it to the gateway. The gateway application receives the data from the sensor node wirelessly and forwards the data to a LabVIEW based TCP client to enable remote monitoring. In this paper, our aim is to study the compatibility of the BLE based platform for ECG monitoring in WBAN and to evaluate its performance experimentally.
3.1.6 LoWPAN over IEEE 802.15.4 Based Stack
To address interoperability issue, an effort to standardize the design of the network layer using the IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) specification effort has recently started. 6LoWPAN is an International Open Standard developed by the IETF that enables building the wireless IoT over IEEE 802.15.4. It enables the efficient use of IPv6 over low-power, low-rate wireless networks on simple embedded devices through an adaption layer and optimization of related protocols [32]. There are huge benefits associated with IoT. These include interoperability, the use of existing infrastructure, tools for remote managing, established commissioning, and diagnosing of IP-based networks. Also, IP technology encourages innovation and is better understood by a wider audience. IP technology is not optimized for PAN but can be adapted to make perfect use of WSN with Internet and this is what 6LoWPAN does. Key features of 6LoWPAN include an efficient header compression, network autoconfiguration using neighborhood discovery, unicast/multicast/broadcast support, fragmentation, and support for IP routing using RPL (Routing Protocol for Low-Power Lossy Networks) [36]. A typical stack of 6LoWPAN is shown in Figure 1.
A typical stack of 6LoWPAN.
3.2. BLE Stack
Although the 6LoWPAN over IEEE 802.15.4 has been adopted by numerous researchers and developers in a variety of their hardware devices, only few studies addressed BLE technology, especially its integration in healthcare applications. As mentioned earlier, BLE is an emerging low-power wireless technology developed for short-range monitoring and control applications and is being included in billions of devices worldwide, currently and in the next few years. For both technologies, 6LoWPAN over IEEE 802.15.4 and BLE, there are tradeoffs that should be considered between the amount of data to be transmitted, network latency, network size, and throughput. BLE provides a single-hop communication which enables its applicability to various healthcare, consumer electronics, and smart energy and security applications. In addition, the IETF 6LoWPAN working group has realized the importance of BLE in IoT and is considering a draft regarding the specifications on how to transmit IPv6 packets over BLE [34].
A typical BLE stack consists of 2 major parts; one is called the “controller” part and the other is called the “host” part. Controller part usually consists of the physical and link layers, implemented in the form of SoC (system-on-chip) with an integrated radio, while the host part runs on an application processor and includes upper layer functionality consisting of logical link control and adaptation protocol (L2CAP), the attribute control (ATT), the generic attribute profile (GATT), the Security Manager Protocol, and Generic Access Profile (GAP). The communication between the host and the controller part is standardized as the host controller interface (HCI). Figure 2 shows the block diagram of BLE protocol stack.
A typical BLE protocol stack [17].
A BLE stack consists of the physical layer that operates at the frequency of 2.4 GHz and makes use of around 40 channels that are 2 MHz apart. There are two types of channels for BLE devices: advertising and data channels. Advertising channels are used for advertisements related activities, device discovery, broadcast, and connection establishment, while data channels are used for transferring data between devices. In BLE, there exists an “advertiser” node that transmits advertising packets through advertising channels at precise time intervals referred to as advertising events and a “scanner” node that acts to receive data using the advertising channels. BLE devices first need to connect to each other before they begin a reliable two-way data communication. The connection between the two devices is an asymmetric procedure in which the advertiser transmits advertisements packets through advertising channels, whereas the other device that is the initiator listens to these packets. Upon receiving those packets, the initiator transmits a connection request message to the advertising device which allows a connection to be established, thus enabling a point-to-point link between both nodes.
The link layer in BLE defines the devices as a master or a slave, which act as initiator and advertiser, respectively, during connection establishment. A master can connect to as many slaves as possible, thus forming a star network. In basic routine operation slaves get into sleep mode and turn themselves on, periodically, to listen to any packets from the master. It is the master, usually, that determines the sleep/wake-up periods of the slaves.
BLE uses a lighter version of the logical link control and adaptation protocol (L2CAP) that was defined for the classic Bluetooth. The main task of the L2CAP is to take care of multiplexing data from the three higher layer protocols, attribute protocol (ATT), the Security Manager Protocol (SMP), and link layer control signaling, onto a link layer connection. In this context, the L2CAP offers a best-effort endeavor to get the data of these services transmitted to the next hop without using retransmission and flow control mechanisms available in earlier Bluetooth versions. Another feature that is dropped from earlier Bluetooth version in the BLE L2CAP is segmentation and reassembly under the assumption that higher layer protocols provide PDUs that fit into the maximum L2CAP payload size, which is equal to 23 bytes in BLE [37].
4. The Proposed Experimental BLE Based Platform
The proposed BLE based system architecture for health monitoring is shown in Figure 3. For sensor nodes (i.e., slaves), we have used a BLE enabled wireless module called BLE112 from Bluegiga [31], which is based on the CC2540 module from Texas Instruments [27]. BLE112 gives immediate benefits; for example, it can host the complete end user applications without the use of an external host or microcontroller and provides host interfaces such as UART in applications, where external host is required. In addition, it provides ultralow-power consumption of 27 mA at 0 dbm, it has a dimension of only 12 × 18 × 2.3 mm, and it allows slave connections for up to 4 connections in master mode. Furthermore, the BLE112 kit comes with a complete software development guide for application and profile development, provides digital and analog I/O's and peripherals for direct interfacing with the sensors, and allows coin cell operation.
BLE based system architecture.
In our setup, we have used a single standalone chip without any external host processor as slave node, in which the complete BLE profile stack and our developed user application are running on the single BLE112 wireless module using BGScript software from Bluegiga. The block diagram of this is shown in Figure 4.
BGScript application block diagram handling data between peripherals and BLE stack using BGAPI.
The slave usually acts as an advertiser which keeps on advertising itself periodically until a connection is established. The advertiser's messages are generally destined for a master that is listening to any advertising device that wants to connect to it. The communication between the master and the slave relies on the GATT, which describes use cases, roles, and general behaviours. Services are collection of characteristics and relationships to other services that encapsulate the behaviour or the device including hierarchy of services, characteristics, and attributes used in the attributes server. Figure 5 describes the relationship between the profile, characteristics, and service in our case.
The hierarchy of our developed peripheral.
We have used BGScript software for programming BLE nodes. A BGScript project consists of XML and BGC files. XML files are used for the definition of the hardware configuration of the BLE module as well as the profile and database definition. On the other hand, BGS files are used for BGScript that is usually responsible for reading the data from the different interfaces of the module (such as I2C, SPI, and UART) and writing them to the profile data base, whenever a certain event happens. Most of the code in this file is event driven, which happens as a result of function call that can either be called by the client which requests the read operation from the server or may happen because of timer expiration or ADC read event or any other event. When the project gets compiled, it transforms the code into a binary OUT file as an image, which is then burnt into the BLE module.
In our project, we have several XML files. For instance, hardware.xml is used for hardware control, GATT.xml contains the information regarding the profile and service description related to the profile, and project.xml contains the information related to the files that will be compiled.
4.1. Gateway Application
For the gateway, a BLE USB dongle is used which acts as a master node and is connected to the Cubox microdesktop [38], which is a low-power ARM architecture that comprises the Marvell Armada 510 (88AP510) SoC with an ARM v6/v7-compliant superscalar processor core. The firmware inside the USB dongle has also been provided by Bluegiga, where the Cubox acts as the external host of the BLE USB dongle. When the USB dongle is plugged to the Cubox, it is detected as a COM port. BGAPI guide has been provided by Bluegiga in order to control and send command to the dongle and to connect to the sensor node that is broadcasting itself. The BGAPI programming is done using simple C callback functions. Figure 6 gives the block diagram of the gateway application and illustrates how the Cubox application interacts with the USB dongle using Bluegiga BGLib that usually runs on an external host.
Block diagram of the gateway application.
On the gateway, we have provided an application in which the BGLib is used on the Cubox connected to BLE USB dongle as host. First, we connected to the device using its broadcast messages, and then we sent commands to discover its services. The sensor node, which in our case is a server, exposes one service only that is the heart rate sensor measurement. Figure 7 shows the services that the server exposes.
Heart rate profile role.
4.2. Remote Application
The measurements are reported in the form of notifications. In order to enable those notifications, a notification configuration of 1 is written. In our case, the node gathers 10 samples of the ADC data and writes them to the GATT database. The sensor node Analog ADC is interfaced with the ECG simulator in order to evaluate the BLE transmission technology for various ECG rates. Once the gateway application starts receiving the data from the node it pushes the same data to the file for record. Moreover, it runs a TCP connection-based server which listens to any remote TCP clients over the WiFi/LAN interface. As soon as the TCP clients try to connect to the server, the remote client starts receiving the updates of the ECG data.
5. Experimental Performance Evaluation
A complete prototype of the proposed healthcare system is implemented in the BLE based experimental testbed described above. The experiments description and parameters as well as the considered performance metrics are detailed in the next sections, followed by the experimental results and analysis of the proposed system.
5.1. Experiments Description and Parameters
The experiments duration is 50 seconds and each scenario is repeated 25 times and averaged. The experimentation parameters are summarized in Table 7.
Experimentation parameters.
5.2. Evaluation Metrics
Quality of Service (QoS) can be characterized generally by data reliability, timeliness, robustness, and availability depending on the application scenarios. In particular, the most fundamental QoS metrics to measure the degree of satisfaction of the service are throughput, end-to-end delay, and packet loss rate [39]. We measured these main metrics to evaluate the performance of our experimental platform.
5.2.1. Throughput
The application throughput is defined as follows:
5.2.2. Packet Error Rate
The packet error rate is the number of incorrectly received data packets divided by the total number of received packets.
5.2.3. End-to-End Delay
The end-to-end delay is defined as the average time taken by packets generated at the source to reach the destination.
5.3. Results and Analysis
In this section, we present the experiment results and analysis of the proposed BLE based platform for ECG data transmission and we compare them to the works presented in the literature.
A significant difference between 6LoWPAN over IEEE 802.15.4 and BLE is the payload size. The maximum size of the payload in BLE112 is 23 bytes, while in the 6LoWPAN over IEEE 802.15.4 based platform we had the payload size of 80 bytes. Note that transmitting one packet with ECG data in the previous platform is equivalent to sending 4 packets in our BLE based platform.
As a result, the peak energy consumption of the BLE based platform is lower than the 6LoWPAN over IEEE 802.15.4 based platform studied previously. This is basically due to the short transmission time of smaller data packets. For instance, in our BLE based platform, we have recorded the peak energy consumption of 27 mA at 0 dbm of transmission power. Note that the obtained peak energy consumption of BLE is slightly higher (27 mA) than those announced in the literature (12–15 mA) [26], while staying lower compared to the 6LoWPAN over IEEE 802.15.4 based platform studied previously in [14], where we have obtained 33 mA at the same transmission power of 0 dbm for the same ECG data.
In the following, we present the experiment results considering the three main performance metrics, throughput, end-to-end delay, and packet loss rate, according to the packet generation rate (PGR), which is the number of packets generated per second at the application layer.
5.3.1. Throughput
The throughput of the BLE based platform against traffic rate (i.e., PGR level) is shown in Figure 8. As expected, the throughput increases with increasing number of packets and reaches its maximum of 210 kbps at PGR = 30.
Throughput with respect to packet generation rate.
Note that the maximum throughput of BLE results obtained experimentally (210 kbps) is very close to the BLE based solutions discussed in the literature (305 kbps) [26, 31] and in [17] (236.7 kbps), as well as those obtained in the 6LoWPAN over IEEE 802.15.4 based platform. In medical applications, the expected data rate is 10 kbps–100 kbps. Even with very high or low data traffic, the throughput remains greater than the requirements. For instance, at PGI = 5 and 45, the system throughput is around 100 kbps. As a result, the proposed BLE based platform has met the requirements for ECG data transmission.
With increasing traffic in the network, beyond PGR = 30, the throughput decreases because of the lost packets due to buffer overflow as the lower layers are not able to handle such increasing traffic generated at the application layer. In these experiments, we have implemented point-to-point communication between the BLE112 sensor acting as a slave and the BLE dongle connected to the Cubox acting as a master for WBANs part. As a result, the collisions and interferences inside the WBANs are not significant as there are no concurrent BLE112 sensors. Therefore, the throughput decrease with increasing traffic is basically due to the capacity of the MAC/PHY layers as well as the hardware of BLE112 sensor node to handle such high data rate.
In future work, we are planning to extend the number of BLE112 sensors simultaneously connected to the BLE dongle to evaluate the collision and interference effects on the throughput of the system.
5.3.2. Packet Error Rate
The packet error rate (PER) is plotted with respect to PGR as shown in Figure 9. The PER is inversely proportional to the data delivery success. Initially, at low packet generation rate, a low packet error indicates the minimum packet loss. Then increasing PGR raises the packet congestion at the lower layers and increases the PER. A light version of logical link control and adaptation protocol (L2CAP) is used in BLE compared to the classical Bluetooth. The BLE L2CAP offers a best-effort endeavor to get the data of the services transmitted to the next hop. As a result, we observe a significant PER with increasing traffic as the BLE112 sensor does not provide retransmission and flow control mechanisms in case of packet loss.
Packet error rate with respect to packet generation rate.
5.3.3. End-to-End Delay
Figure 10 depicts the end-to-end delay versus offered traffic load. Initially, at low packet generation rate, the minimum end-to-end delay is obtained due to the low number of packets transmitted without congestion. With an increase of the traffic, the end-to-end delay increases due to high congestion in lower layers. Note that even with high traffic the end-to-end delay of our BLE based platform remains low. For instance, we observe only 60 ms of end-to-end delay with the maximum throughput of 210 kbps at PGR = 30. Even though the end-to-end delay of BLE results obtained experimentally with the maximum throughput is significantly higher (60 ms) than those announced in the literature (2.5 ms) [26, 31], it still remains much lower than the required latency of 125 ms in the medical applications as well as 250 ms required in the nonmedical applications.
End-to-end (ETE) delay with respect to packet generation rate.
To resume, the proposed BLE based solution showed a good potential and has met the main requirements of the u-healthcare applications in terms of the performance, while staying energy efficient. Note that the adaptive frequency hopping of the BLE may bring about more robustness with limited interference. In our future work, we are planning to study its capacity to deal with the interference and collision in WBAN. However, for ECG data monitoring, an important drawback of the BLE based system is its small size of payload (23 bytes), while in the 6LowPAN over IEEE 802.15.4 based platform we had the payload size of 80 bytes. As a result, to transmit one packet of ECG data, we need to send 4 packets with BLE. In addition, the BLE based solution allows only star topology in WBANs, while the 6LowPAN over IEEE 802.15.4 based platform could provide star and mesh topologies, which enables us to take advantage of the redundancy created by wireless communications.
6. Conclusion
We proposed a BLE based platform for u-healthcare applications for ECG data monitoring. The BLE112 sensor node (acting as a slave) from Bluegiga is used to measure ECG data from a patient and transmit to a BLE dongle (acting as a master) connected to Cubox (embedded platform acting as a gateway), which provides connectivity to a remote PC through WiFi and 3G/4G. The performance of the proposed BLE based system was evaluated experimentally. Experimental results showed that this solution has met the requirements of u-healthcare applications in terms of throughput, end-to-end delay, and packet error rate, while being energy efficient. The peak energy consumption of the BLE based platform was 27 mA at 0 dbm, which remains lower than 33 mA of the previously studied 6LowPAN over IEEE 802.15.4 system at the same transmission power. Moreover, the very small size of 12 × 18 × 2.3 mm of the BLE112 makes it very convenient and suitable to use as a wearable device for health monitoring applications. However, for ECG data monitoring, an important drawback of the BLE based system is its small size of payload (23 bytes), which requires sending 4 packets in the BLE based platform to transmit 1 packet of ECG data. In future work, we are planning to increase the number of BLE112 sensor nodes simultaneously connected to a master node, in order to evaluate the collision and interference effects on the system performance. The BLE adaptive frequency hopping mechanism seems interesting as it may provide better robustness to interference and collisions.
Footnotes
Disclaimer
The statements made herein are solely the responsibility of the authors.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgment
This paper was made possible by NPRP Grant no. 4-1207-2-474 from the Qatar National Research Fund (a member of Qatar Foundation).