The developed prototype of the monitoring system is integrated by the next subsystems, as shown in Figure 1.
-
(i)
A Bluetooth BAN which is formed by a pulse-oximeter, a GPS receiver, and a smartphone. The smartphone along with the Python-developed control application acts as the Node of Control (NC) or master node (coordinator) of the Bluetooth piconet.
-
(ii)
A Central Control Server (CCS) consisting in a web server with Python support, which centralizes the monitoring information received from the NC.
-
(iii)
The remote Control and Monitoring Units (CMUs): a web application in charge of the control and monitoring of the BAN network. The developed web application should run in any conventional computer or mobile device with an Internet connection and a web browser.
All these components of the system and the communications interfaces between them are described in the following sections.
3.1. Architecture
3.1.1. BAN
The Body Area Network is integrated by the following components.
-
(i)
A Nonin 4100 [35] pulse-oximeter and a GPS receiver, both provided with Bluetooth interfaces.
-
(ii)
The Nonin 4100 pulse-oximeter measures several vital parameters, such as the heart rate (HR), the saturation of peripheral oxygen (SPO2), and the perfusion level. The pulse-oximeter supports two operational modes: (i) under simple mode 1, the device sends only 3 octets per second with basic information about the health status (basically the SPO2 value and the heart rate); (2) under the verbose mode 2, the device transmits three packets per second. Every packet includes 25 five-octet frames, which encapsulate the information of the plethysmogram, two different averaged estimations of the HR and the SPO2, and the battery status. On the other hand, the GPS receiver has been included considering the application of the system in a real scenario. The GPS would allow the emergency team to locate the patient in case of detecting alarm conditions.
-
(iii)
A Nokia smartphone with Symbian OS S60 [36] (Series 60 User Interface), Python support, and Bluetooth and Wi-Fi [37] interfaces has been employed as the hardware platform for the NC component. The main reason to select a smartphone is the wide diffusion of these handheld devices in the market of consumer electronics. In fact, the total sales of smartphones in 2009 have attained a 36.4% of the global sales of mobile phones [38]. Besides, another advantage of using smartphones is the familiarity of general users with these electronic gadgets as well as the quick and easy installation of applications, such as what is concluded in [14].
For the NC component a Python application, whose graphical interface is shown in Figure 2, has been developed. This application provides the following functionalities:
-
(i)
local configuration of the BAN (selection of sensors to be monitored),
-
(ii)
establishment and management of Bluetooth communications with the BT devices of the BAN,
-
(iii)
local monitoring: For this mode of operation, the application only shows a screen depicting the data received from the sensors,
-
(vii)
remote monitoring: The application connects with the CCS server in order to forward the data measured by the sensors,
-
(iv)
management and execution of the configuration commands which are received from the CMU unit through the CCS,
-
(v)
detection and notifications of events that occur when the heart rate (HR) and saturation of peripheral oxygen (SPO2) are out of the normality range (whose values can be remotely programmed).
3.1.2. Central Control Server (CCS)
The internal structure of the CCS server is shown in Figure 3. The main component is the PyMHealth application, developed with Python programming language. This application has been deployed on CherryPy [39], an object-oriented HTTP (Hyper Text Transfer Protocol) [40] framework encoded in Python, which provides both a web server and an application server. Besides, as persistent layer, SQLObject [41] has been employed as it supplies a common object-oriented interface for different database management systems (DBMSs): PostgreSQL, MS SQL Server, SQLite, Sybase, and MySQL. Particularly, in a first prototype, MySQL [42] has been selected as DBMS, due to its simplicity and because its source code is available under the terms of the GNU General Public License [43].
The other components in the CCS are the following:
-
(i)
An open source MQB (Message Queue Broker) that fully implements the Java Message Service 1.1 (JMS) [44], Apache ActiveMQ [45]: it has been used to forward the data of the patients to the CMUs. For the communication of the PyMHealth application with this broker the messaging protocol STOMP (Streaming Text Orientated Messaging Protocol) [46] has been chosen.
-
(ii)
A comet server, Orbited [47]: this element allows that external applications interact with the messaging broker with HTTP protocol. Comet servers are web servers that permit sending data to a web client as soon as these data are generated, without waiting for any HTTP request from the client.
3.1.3. Control and Monitoring Units (CMUs)
For the CMU component a web application, coded in JavaScript [48] and based on AJAX, has been developed. The advantage of using JavaScript is that the most popular web browsers include a native implementation of this language. Therefore, CMUs do not require the installation of any additional software or plug-in. On the other hand, AJAX technology enables CMUs to establish asynchronous HTTP connections in order to obtain data from the patients. In this way, the data visualized in the browser are automatically updated, without refreshing the web page continuously.
The CMUs retrieve the patient's information by accessing the web pages which are dynamically executed and generated by the CCS server. The main page is the DHTML (Dynamic Hyper Text Markup Language) [49] page "Monitor.htm," which is depicted in Figure 4. This page displays the monitored biosignals while it offers a simple interface to set up the configurable control parameters of the sensor. Thus, this page contains all the logic required by the communications with the CCS server for the reception and representation of the data collected by the sensors, as well as for sending configuration commands. Depending on the nature of the monitored signals, this page is automatically updated by using JavaScript routines and the DOM (Document Object Model) [50] interface. Specifically, aiming at obtaining the data corresponding to a particular sensor, the JavaScript object XMLHttpRequest [51] is employed. The execution of this object takes into account the differences between the most popular web browsers (so that the CMUs can be deployed on any common browser in a transparent way for the user). For example, the initial versions of Microsoft Internet Explorer [52] do not include a native implementation of XMLHttpRequest interface. In this case, the program automatically imports the ActiveX [53] object from the Microsoft XML Parser (MSXML) library [54].
3.2. Interfaces between Subsystems
3.2.1. Communication between the Node of Control (NC) and the Central Control Server (CCS)
For the communication between the NC and CCS components, based on HTTP Protocol, two channels are employed.
-
(i)
Data Channel. The goal of this channel is to collect in the CCS the biosignal data that are forwarded by the NC. The NC can be optionally configured to transmit continuously. Thus, for any packet received from a device connected to the BAN, the NC sends to the CCS a POST HTTP message, whose body encapsulates the sensor data. Conversely, if the transmission has been set in a periodic basis (with a configurable period), all the packets received during the last period are assembled to be transmitted in a single HTTP request. In any case, the data are encoded into JSON (JavaScript Object Notation) [55], which is a text format based on a subset of JavaScript literals (Standard ECMA-262 [56]). JSON is independent from the programming language but it shares notations with some languages, including Python. JSON has been selected instead of other formats, such as XML (eXtensible Markup Language) [57], due to its simplicity for encoding/decoding and because it is lighter in weight than XML.
-
(ii)
Control Channel. This channel is conceived for the transmission/reception of configuration commands. By means of this channel the NC component periodically sends GET HTTP requests to the CCS in order to get the pending configuration commands. The frequency for this polling process is also a configurable parameter of the NC.
The way in which HTTP is utilized differs for these channels.
-
(i)
In the case of the data channel, standard HTTP mode is used for periodic transmissions. On the other hand, for continuous transmissions, HTTP pipelining mode is employed. This nonblocking mode allows sending several consecutive requests without having to wait for the corresponding HTTP responses from the server. For this purpose, pipelining mode requires that the underlying HTTP connection operates in persistent mode. Consequently, the latency is minimized as the handshake and the overhead of establishing a new connection for each request is eliminated. Thus, the reuse of existing connections significantly improves the performance of the application.
-
(ii)
The Control Channel utilizes the HTTP polling mode. This mode permits the client to query the server at regular intervals in order to get data which are asynchronously updated in the server.
The management of both data and control channels is centralized in a dedicated thread formed by three active objects. Two of them are responsible for the data channel: one is only in charge of sending HTTP requests, while the other one receives the responses from the server. Concurrently, the third active object periodically polls the server querying about the pending commands.
3.2.2. Communication between the Central Control Server (CCS) and the Control and Monitoring Units (CMUs)
To acquire the data received by the CCS from the NC, the CMU units could periodically send HTTP requests to the server. In that case, the period of these requests should be short enough to guarantee the real-time signal monitoring. However, this conventional method could negatively impact on the system performance in several respects: less available bandwidth, more battery consumption (which would entail a serious problem for portable CMU units) and an unnecessary overload of the server. Alternatively, in order to avoid these drawbacks, the data received from NC are asynchronously forwarded by the CCS to the CMU units. For this purpose, the publish/subscribe model, also known as streaming HTTP, has been adopted. This communication model is a functionality provided by the Orbited daemon, a Comet server based on Twisted [58] (a Python event-driven framework for asynchronous communication between processes).
As it has been previously mentioned, the MQB Apache ActiveMQ and STOMP protocol are employed to forward to the CMU units the data of the sensors. Specifically, the PyMHealth application is responsible for publishing the data received from the NC at the queue of the MQB identified as /topic/ban/sensor, where ban and sensor parameters, respectively, define the source BAN and sensor from which the data are being received. Besides, depending on the data to be monitored, every CMU has to subscribe to the corresponding queue. So, whenever a new STOMP message is received, a JavaScript function is invoked to extract data, which are encoded into JSON.
The STOMP client used by PyMHealth application to publish the data is a Pyhton client, while the client program that is executed on the CMU side is a JavaScript pull client provided by the Orbited daemon.
Additionally, three specific control commands have been contemplated to remotely configure the pulse-oximeter. These commands can be selected by the user in the DHTML page "Monitor.htm" (as it is represented in Figure 4). These commands define the operational mode of the sensor and the alarm thresholds for the HR and the SPO2 signals. Moreover, a general command has been included to configure the data transmission in a continuous or periodic basis. The CMU unit generates an HTTP POST request by using JavaScript object XMLHttpRequest. This POST HTTP request, sent to the CCS server, encapsulates the commands (which are encoded into JSON) together with the identifier of the BAN which the commands are targeted to.