Abstract
The Internet of Things (IoT) is growing at a fast pace with new devices getting connected all the time. A new emerging group of these devices is the wearable devices, and the wireless sensor networks are a good way to integrate them in the IoT concept and bring new experiences to the daily life activities. In this paper, we present an everyday life application involving a WSN as the base of a novel context-awareness sports scenario, where physiological parameters are measured and sent to the WSN by wearable devices. Applications with several hardware components introduce the problem of heterogeneity in the network. In order to integrate different hardware platforms and to introduce a service-oriented semantic middleware solution into a single application, we propose the use of an enterprise service bus (ESB) as a bridge for guaranteeing interoperability and integration of the different environments, thus introducing a semantic added value needed in the world of IoT-based systems. This approach places all the data acquired (e.g., via internet data access) at application developers disposal, opening the system to new user applications. The user can then access the data through a wide variety of devices (smartphones, tablets, and computers) and operating systems (Android, iOS, Windows, Linux, etc.).
1. Introduction
Modern society is looking for user-friendly aiding systems, able not only to remotely monitor the health of the elderly and people suffering from chronic diseases, but also to find a safe and efficient routine to practice some sport or single exercises in an outdoor or indoor environment (such as gymnasium), in order to improve each person's level of fitness and health. In this context, Internet of Things (IoT)-related systems are able to bring solutions.
The IoT paradigm can be built using wireless sensor networks (WSNs) as the leading technology to acquire and manage data. Connecting other smart elements to a WSN (smartphones, watches, tablets, etc.) may also improve the user experience in the IoT, and it could act as a starting point for the use of the technology. If the smart devices are wearable, the first technology-access barrier is broken: the user just has to “wear” the technology as a daily-life garment.
A differential value of a WSN node is the fact that any external sensor can be connected in an easy way to itself, and the data sensing does not depend on the network management. For example, if the application needs biometric or human physiological parameters (blood pressure, heart rate, breathing rate, etc.) an external sensor must be connected in some way to the node. A very easy and fast solution is using wireless communications protocols, such as Bluetooth. However, in this scenario a new challenge springs up: the existence of different types of devices or platforms (as there is no standardization in this kind of sensors), so it is desirable to abstract the hardware features and protocols from high-level layers. This can be done with an intermediate level, called middleware [1]. It would be very useful if this middleware level is able both to process environmental measures, but, and receiving user parameters with several sensors: localization, speed, health status, preferences, and so forth. In this way, a context-awareness system could be developed, and new services are able to be included in the applications without any other external intervention.
In this paper, we present a physical application involving a WSN as the foundation of a sports-related scenario. Gathering environmental and human physiological data and storing a user's profile can lead into an autonomous physical condition performance system, where the preferences and needs of every single user are evaluated to obtain safe and optimum exercise routines. Our proposal has three key novel components. The first one is the integration of several wearable devices in the Internet of Things world. In order to integrate these devices (provided with only Bluetooth connection), we have implemented a dual-protocol WSN/Bluetooth node. In our proposal, we use two of these nodes: one connected to the wearable health-data monitor and another node connected to the smartphone or smartwatch. With these nodes, all the information from/to the wearable devices can be managed in the same way as the information from other WSN nodes. Any new wearable device can be included in our system, with the only limitation of being Bluetooth compliant, and the services offered by this new device can be discovered and used as well. The second contribution is the development of an ontology, included within the service-oriented semantic middleware, to model the services provided by the WSN. With the semantically annotated services it is possible to compose new services based on the existing single services, widening the platform for future applications. The third key contribution is the integration of an enterprise service bus (ESB) in a WSN for an IoT-based application. With the ESB, all the services published by the WSN nodes (including the services available at the wearable devices, such as heart rate and body temperature) are available for third-party applications. If the ESB is connected to the internet, any external application can use our RESTful API to make requests to the published services.
This paper is divided as follows. In Section 1, we introduce wireless sensor networks features and applications as the foundations of an Internet of Things-designed application. In Section 2, we present a series of works related with healthcare and smart spaces using WSNs. We present the contextualization of the requirements for a sports monitoring system with wearable devices in Section 3. In Sections 4 and 5, an ESB platform for middleware architectures and ontologies interoperability is described. Section 6 presents the testing scenario description. Section 7 includes the conclusions and future work to develop from this paper.
2. Related Work
The Internet of Things is gaining the attention of researchers worldwide. In [2], Miorandi et al. present a survey of technologies, applications, and research challenges for the IoT. The most relevant challenges are related with distributed systems technology and distributed intelligence. Related to applications, the survey remarks the idea of RFID as the base of the IoT paradigm, but other technologies are expected to emerge in order to bring the paradigm to real-life applications, identifying six ones which they believe can play a leading role in the adoption of IoT technologies: environmental monitoring, smart cities, smart business/inventory and product management, smart homes/smart building management, healthcare, and security and surveillance.
Due to the characteristics of wireless sensor networks, they are getting an important place in e-Health applications and assisted living. WSNs are flexible to integrate into health environments, not intrusive, not high priced, small, easily portable, and, in some cases, wearable.
In [3], Mileo et al. present an intelligent home environment to monitor a patient in a context-aware setting. The goal is to control the evolution of patient's health and home environment. They propose a middleware environment to provide routing, topology control, and data aggregation, so they can carry the data collected by the sensors to feed the reasoning system. The system is not detailed in the paper, and the latter does not clarify whether the system has been deployed in a real WSN or not, though.
An already implemented solution is presented by Wood et al. in AlarmNet [4]. It is an assisted living and residential monitoring network for pervasive adaptive healthcare in assisted living communities with residents or patients with diverse needs. The system is composed by an extensible heterogeneous network middleware, bidirectional network information flow protocols for environmental systems, resident data flow analysis, and a query protocol for efficient streaming. The researchers built a test bed with MicaZ and Telos Sky nodes, where the system was deployed and tested.
Philips Research Europe and the Department of Biomedical Engineering at the Imperial College London have developed an end-to-end and generic infrastructure [5] that allows the application optimization by developing services distributed over a “Wireless Accessible Sensor Populations” (WASPs) network. Their goal is optimizing the battery life of the nodes monitoring needs of individual persons. They validated the system with realistic elderly care scenarios: monitoring activities of daily living, hypothermia, and ECG arrhythmia. This project is focused overall on controlling physical parameters from elderly people, acting in case of danger, taking into account the different vital data from each person. For this end, the person must bring along a node, and it might not be accepted by everybody due to its size.
In [6], the design problems of an ambient home care system relying on WSN are addressed. The approach is composed by traditional WSN nodes and also includes personal mobile devices, deploying a heterogeneous sensor network, integrated into an OSGi framework. The most notorious weakness is that this proposal was based on the idea that personal mobile phones and medical equipments would have integrated, in a near future, ZigBee protocol.
Qixin et al. present in [7] an architecture for assisted living that allows independent parties work together in a dependable, secure, and low-cost fashion with predictable properties. This approach is based on an Assisted Living Service Provider (ALSP) who provides a server that collects and maintains encrypted assisted persons' (APs) records. ALSP can be a third party distinct from APs, communication providers, and clinicians; or it can be part of a hospital or a similar facility by using standards such as XML and Java technology in WLAN networks.
In [8], the EU funded a project called ANGEL (Advanced Networked embedded platform as a Gateway to Enhance quality of Life) focuses on the development and deployment of wireless sensor networks building ambient intelligence systems for assisted living and personal health monitoring. The provision of security services such as confidentiality and authentication is a fundamental requirement for ANGEL in order to ensure the safety and privacy of the users; the development is challenging due to the high mobility of users accessing a multitude of wireless sensor networks. Based on keying material distribution, they provide a solution for the secure configuration of sensors and gateways. This ensures that users can interact with their system in an easy, transparent, and safe way. The proposal architecture is based on the ZigBee standard and consists of body and home sensor networks and gateway nodes. Although the ANGEL system is very concerned about security issues, they do not perform a full ambient assisted living platform.
Smart devices (phones, watches, etc.) have become common life elements. Their capability to acquire and to process complex data is growing with new devices and new operating systems (iOS, Android, etc.). Wireless devices can monitor not only environmental parameters (temperature, humidity, etc.) but also several human body parameters, like blood pressure, heart rate, breathing rate, body temperature, and so forth. The communication between these devices, conforming a body area network (BAN), and internet-capable devices (as the already mentioned smart ones) produce a wide new range of protocols and applications, as presented in several proposals [9–15].
Moreover, several sensor-specific ontologies have been proposed. For example, sensorML [16] specifies models and XML encoding providing a framework within which the geometric, dynamic, and observational characteristics of sensors and sensor systems can be defined. Based in sensorML appeared ontoSensor [17], a prototype sensor knowledge repository compatible with Semantic Web infrastructure.
In this paper, we propose a sports environment monitoring system, where environmental parameters (i.e., room temperature), physiological data (breathing rate, heart rate, etc.), and user's profile (weight, height, goals, thresholds, etc.) are combined to offer the user safe and efficient suggestions of sport routines in order to improve his/her physical condition. Also, the system will send the user an alarm from an available set if any hazardous condition appears (i.e., a high heart rate value) or any of the defined user upper or lower thresholds are surpassed. The user devices are noninvasive wearable ones: smartphone, pulse meter, smartwatch, and so forth.
The system foundations are a service-oriented semantic middleware and an ontology to model the services provided by the WSN. Furthermore, it is possible to compose new services based on the existing single services, using the context-awareness provided by the middleware. In order to integrate different middleware architectures or ontologies in a single user application, an enterprise service bus (ESB) has been included in the system. This element is an efficient solution to abstract the application layer of the sensors heterogeneity related issues and an easy way to manage the introduction of new middlewares or WSN platforms in the system. The user application just needs to access a defined URL to retrieve the desired parameter, abstracting the underlying WSN platform. If there is a need of integrating a new ontology or sensor, the changes are minimal and only involve the creation of a new bundle inside the ESB and a new URL definition.
3. A Real Sportsman Monitoring System: Contextualization and Requirements
The sports environment monitoring system proposed in this paper is based on a sport area (gymnasium, stadium, etc.) with a sensor network (WSN) spread all over it. The WSN is sensing environmental data, such as light, temperature, humidity. What is more, the user will be provided with a device compatible with the installed network, with the tasks of identifying the user inside the mentioned network and retrieving data. This functionality can be included in a device previously carried by the user (e.g., a smartphone or a smartwatch). These devices send the data to a WSN node equipped with a Bluetooth interface, so no cables are needed to establish the communication. A unique user ID is assigned and represents the user's profile in the system. This profile includes several user parameters: sports routines, fitness, thresholds, and so forth.
Once the user enters the network coverage range, the device transmits the identifier over the network. This way the system always knows which users are in which area. With this information, as well as the environmental data sampled by the sensors (humidity, temperature, lightness…) and the specification stored for each profile, the network makes decisions concerning the performance of the sport practice and suggests the user a set of exercises (user context). Then, the network starts monitoring the user's physiological data (heart rate, breath rate, ECG, etc.) and compares them with the thresholds stored. A general scenario overview is shown in Figure 1. The components are ESB, sink, sensor nodes, and Bluetooth devices. The user can carry a communication device (i.e., a smartphone or a smartwatch) to interact with the system and receive alarms.
Scenario overview, including key elements: ESB (to integrate different middleware implementations), WSN (with two Bluetooth-enabled nodes), and user's devices (a smartphone, a Zephyr body sensor, and a smartwatch).
4. Service-Oriented Semantic Middleware and Service Ontology Description
As introduced in the first section, middleware is an abstraction layer between the wireless sensor and the application layer. The middleware architecture used in this proposal is a service oriented semantic middleware developed in our researching group, named nSOM [18], a service-oriented framework designed for WSNs. Based on a dynamic service composition model and a semantic knowledge management scheme, it provides an agent-based virtual sensor service approach that is able to create new composed services combining the existing ones. nSOM is being extended to include more semantic and context-awareness services.
The services that the WSN offers to the applications rely on measures obtained by the sensors (environmental or physiological). These measures are delivered to a broker that compounds and offers the service. Moreover, this semantic middleware architecture proposes the semantic annotation of the service provided by WSN to get a couple of advantages. The annotation of the services is based on an ontology developed specifically for these services. Ontology is a formal representation of a set of concepts within a domain and the relationships between those concepts. The ontology proposed here is not sensor related, as mentioned ontologies (sensorML or ontoSensor) are, but it is related with the services provided by low capabilities devices integrated in a WSN. Thus, our ontology provides several advantages provided by semantically annotated services.
Applications that use these services can retrieve from the ontology repository the profile and the features of the services, being able to choose the most appropriate according to its function. The service composition can be done within the WSN, so the generation of new services is a new feature provided by the WSN. Accurate knowledge of the environment in which services are provided. Controlling the function of the service. Adequate the service to the current state and capabilities of the wireless sensor networks.
The ontology description is divided into three parts: profile, process, and context. Profile is the description of the features of the service, and it must be published in an ontology repository in order to be queried by applications or other users before the use of the service. The profile class is composed of service identification, service functionality, security profile, and grounding. Process description of the service is the most important part of the ontology, as it contains the classes related with the process that is behind of the service delivery. The process class is composed of operation, atomic process, aggregated process, and input and output. An important contribution of this ontology is the specification of the context condition under which the service is provided. There are several differences when providing a temperature service indoors or outdoors or a heart rate service at sea level or on the top of a mountain. The context information can be written in the ontology repository and can be used by processes to provide the service. An example of semantic annotation in JSON is provided in Algorithm 1.
{/*service*/ “profile”: {/*start profile*/ “identification”: { “serviceName”: { “identif”: “Real-Time Pulse”, “idService”: “idInto SmartSpaceLifewear” }, “serviceDescription”: “Real-Time pulse”, “owner”: “lifewear” }, “functionality”: { “preconditionDescription”: “empty”, “inputDescription”: “empty”, “outputDescription”: “pulse rate” }, “security”: { “policy”: “security policy lifewear”, “dataProtection”: “integrity” }, “grounding”: { “inputMessage”: “empty”, “outputMessage”: “control, integer”, “endPoint”: “/lifeware/pulse/” } }/*end profile*/ }/*end service*/
Service composition can be done using the base of the already existing services. The new service will be published as a “virtual” service, by a special node called orchestrator. The virtual service is, for all the nodes in the network but the orchestrator, a similar service to the noncomposed ones. When a request for a service reaches the network, the broker will deliver the request to the node that has previously published that service: a sensing node if it is a single service or the orchestrator node if it is a composed service. Once the request is received by the orchestrator, it will be split into single service requests. All of these requests will be sent to the corresponding nodes, and when the orchestrator has all the data needed, it will reply to the composed service request. The only noticeable difference will be the time needed to process the request. An example to illustrate the service composition could be a service called “injury prevention”, which is composed of three single services: body temperature, breathing rate, and heart rate. This composed service, according to the values of the three single services, will return a “low”, “medium”, or “high” injury risk.
5. Enterprise Service Bus Platform for Middleware and Ontology Interoperability
In order to obtain a generic integrative and scalable solution, the use of an enterprise service bus (ESB) was decided.
An ESB is a software architecture model based on the service-oriented architecture (SOA) paradigm used for designing and implementing the interaction and communication between interacting software applications. It provides an asynchronous message oriented communication between the applications inside the bus. The strength of the ESB solutions is the integration of heterogeneous solutions inside a unique communication bus.
Following the specification of the generic client server architecture, the client requests are routed (and adapted if necessary) to the corresponding service, which will answer the petition. In fact, the client sends the request to the ESB (instead of sending it to the application server), and the ESB is responsible for routing the request to the server, monitoring and logging the traffic. This approach exposes a unique external interface to access different applications lying behind the bus (or, in this approach, different middleware architectures). Thus, the updating and migration issues are easier to manage.
A general overview of the integration provided by the ESB to external applications is shown in Figure 2.
An ESB for different consumers and middleware implementations (center), with a smartwatch attached (left). The services can be consumed by a wide range of applications, for example, a mobile application (right).
Components use the bus to communicate between them, reducing the underlying number of connections. By doing this, debugging errors or changing components is easier. The ESB can be distributed, improving the scalability and resilience features of our system. The user application would be able to communicate with the ESB by means of the external interfaces. The ESB solution contributes to integrate all the system components, but it does not solve by itself the semantic and context-awareness issues. Here is where our proposal gives the solution with the nSOM middleware, integrated inside the ESB as a producer bundle.
5.1. External ESB Interfaces
Several interfaces for clients to access the ESB published services have been defined. In order to simplify the system and have lightweight clients, Representational State Transfer (REST) protocol and JavaScript Object Notation (JSON) [19] messages are used. Both are well-known and widely used technologies in mobile and smart devices, giving the opportunity to external developers to create new applications using the existing smart wearable network interfaces.
In order to provide the services needed for the sportsman scenario, the already mentioned nSOM middleware has been extended to include semantic annotations to the services published by the WSN. The definition of the sports scenario includes several interfaces to access the services published by the network. In Figure 3, there are some of these interfaces represented: pulse, distance, breathing rate, and injury prevention.
External interfaces for third-party user applications.
If a client wants to access any of those services, it needs to send a REST request (in a URL formatted HTTP packet) to the endpoint of the application and the path of the service. The ESB will receive the request, route to the corresponding application, and return the response to the client in the specified format. In this case, all the service responses have the same format (JSON/XML inside an HTTP body response).
6. Testing the System in a Real Scenario and Results
In order to test the functionality of the proposal, a scenario defined inside the research project “LifeWear-Mobilized Lifestyle with Wearables” [20] was used. The system was deployed in a real sportsman scenario: the Technical University of Madrid (UPM) student's gymnasium.
The user's body parameters (heart and breath rate, body temperature, etc.) were measured by a wearable sensor and sent to a special WSN node via Bluetooth. A general overview of the Lifewear testing scenario is presented in Figure 4.
Lifewear testing scenario components and communication protocols (down) and data provided by the Zephyr body sensor and SunSpot nodes (up).
The architecture was deployed over a commercial WSN node solution: SunSpot platform [21], manufactured by Oracle. Main characteristics of SunSpot hardware platform are ARM 920T CPU (180 MHz—32-bit); 512 Kb RAM and 4 Mb FLASH; and a 3.6 V rechargeable 750 mAh Li-Ion battery. In terms of security and privacy, the platform used to implement the proposed system including mechanisms to cipher all the information inside the WSN. The SDK includes libraries providing booth symmetric and asymmetric cryptography mechanisms. For symmetric cryptography, the ciphering algorithm used is AES (Advanced Encryption Standard), and RSA is used for asymmetric cryptography. Moreover, it is also possible to use elliptic curve cryptography (ECC) algorithms in the last update of the platform SDK. A secure communication can be established using secure radio streams, which reuse Secure Sockets Layer (SSL) protocol underneath with ECC.
The ESB implementation used was Fuse ESB [22], an open-source implementation based on Apache ServiceMix. It supports JBI and OSGi for use in enterprise IT organizations. Any standard JBI or OSGi-compliant service engine or binding component—including BPEL, XSLT, or JMX engines—may be deployed to a Fuse ESB container, and Fuse ESB components may be deployed to other ESBs.
The smartwatch used was WIMM, a commercial watch developed by WIMM Labs [23]. It is an Android-based watch, so it was necessary to develop Android applications for the project. This application is able to show alarms to the user in real time if any hazardous value is reached. As an open platform, Android gives the opportunity to any developer to create a new application for our WSN, using the interfaces provided to access to our services. A smartphone application was also developed within the project, and it provides the user a full access to all the system services: exercise routines, alarms, profiling, historical data record, and so forth.
In order to obtain user data (pulse rate, breathing rate, temperature, position, etc.) a wearable device is the most suitable solution. For evaluation purposes, a commercial solution was integrated in the platform: the Zephyr BioHarness Bluetooth device [24]. BioHarness BT enables the capture and transmission of comprehensive physiological data via Bluetooth, providing remote monitoring of human performance and condition in the real world. This sensor can monitor heart rate, breathing rate, body temperature, body posture, and activity levels. The sensor sends data every second by default, but it can be configured if the application needs another data sampling rate.
6.1. Results
With all the elements connected and the network deployed, several time measurements were obtained: startup time of the network elements, service response time, and nodes lifetime. Also, the amount of memory used in the nodes to run the applications was measured.
The full system startup time was tested in order to determine the time that the user needs to wait before starting the usage of the platform. The results for the most relevant elements are shown in Figure 5. The ESB startup time is long (13000 milliseconds), since it is the time period for an ESB Linux-based machine to bootup. The Zephyr device boot-up time is longer than a regular node because it needs to set up the Bluetooth link with the WSN node.
Network elements startup time.
The reading data delay introduced by the ESB is also high (4 seconds), and it must be improved in order to avoid bottlenecks in the network. The physiological data is sampled by the Bluetooth device every second and remains stored until the ESB performs a data query or an alarm is issued. Although the use of an ESB in the network introduces a delay, the integration and scalability facilities offered by the ESB justifies the use of this element. Moreover, in our testing scenario the alarms can reach the smartwatch in a direct Bluetooth connection, so real-time alarms delivery is guaranteed.
The response time for simple and composed service queries is shown in Figure 6. It is remarkable that the injury prevention composed service request takes longer, since it has to be received by the broker, and then wait for the composing request to be processed (as explained in Section 4).
Response time for different service queries: simple services (temperature 1, 2, and 3 and body temperature) and composed service (injury prevention).
Node lifetime is an important factor in the application. Depending on the role assigned, the same node battery would last different time. For example, the most active nodes are the ones carrying on the Bluetooth connection. Thus, these nodes need to be charged every 6 hours of continuous activity. Other nodes lifetime are shown in Figure 7. In a sportsman scenario, it is admissible that the user devices can be recharged when the activity has ended, and the WSN nodes can be recharged every day when the activity center closes (e.g., in a gymnasium every night). If the application requires a longer node lifetime, the duty cycle and the data sampling frequency can be modified in order to reduce the energy consumption.
Power consumption of the different nodes, measured in lifetime hours.
Also the amount of memory used by the source code was measured inside the nodes. The most important data is shown in Table 1. The amount of memory used is low, and there is enough free space to store application data or to scale up the system.
Memory usage in the SunSpot hardware platform.
7. Conclusions and Future Work
In this paper, we have presented an autonomous physical condition performance system, based on a WSN, bringing the possibility to include several elements in an Internet of Things scenario: a smartwatch, a physiological monitoring device, and a smartphone. The integration of these wearable devices has been accomplished using Bluetooth, wireless sensor networks (to connect all the system components), and smart services (in order to publish all the facilities offered for each of the devices).
Also, the proposed solution includes a novel element in a WSN: an enterprise service bus (ESB) as an integration element for different middleware implementations and platforms. The ESB introduces a network delay, but, on the other hand, provides the system with middleware integration and scalability features. The middleware used (nSOM) also provides context-awareness and service composition features, creating a fully deployed real-life application for a sportsman scenario.
The system acquires the physiological data from a Bluetooth commercial device. With these data and the user's profile, the application suggests to the user a series of exercises to improve his or her fitness condition. If a hazardous level of any vital parameter is reached (e.g., heart rate), an alarm is issued and alerts the user to stop doing the workout. This alarm can reach a smartphone or a wearable smartwatch and, if configured, the emergency services through the ESB. All the tests and the measures obtained were carried out in a university campus gymnasium with satisfactory results for the users.
Although our proposal is a generic framework for applications based in services provided by wearable devices, we have included an application scenario for testing purposes. This is an indoor scenario, because it is fairly complex to cover an outdoor sports scenario with a WSN. Furthermore, in an outdoor scenario with a moving user, the issues of tracking, mobility, and localization must be addressed. The service-oriented semantic middleware and service ontology used were designed to be fully scalable. The nSOM agent-based virtual sensor service was implemented to deal with all the scalability and upgrade issues. Thus, new nodes and/or agents managing the user's mobility can be deployed and registered. Since the services are dynamically composed, new services can be added with no issues. Another limitation is that the enterprise service bus is now deployed in a PC machine. Small-sized equipment (such as mini computers with limited resources, e.g., Raspberry Pi, Pandaboard, BeagleBoard, or any other open-hardware platform) with the ESB implemented could be tested in order to include it in our proposal.
Future work will consider including new Bluetooth devices (bathroom scale, GPS tracking device, etc.) in order to improve the accuracy and efficiency of the suggested exercises. Delay times can be improved by using smart routing algorithms. We are working to migrate the network infrastructure to the 6LoWPAN RFC of the IETF [25].
Footnotes
Conflict of Interests
The authors declare that they have no conflict of interests to disclose.
Acknowledgments
The work presented in this paper has been partially funded by the Spanish Ministry of Industry, Tourism and Trade in the framework of the European Research Project “LifeWear-Mobilized Lifestyle with Wearables” (TSI-020400-2010-100), which belongs to the ITEA 2 (Information Technology for European Advancement 2) program. The user's mobile application has been developed in collaboration with SAI Wireless, within the Lifewear project framework.