Enabling the IoT paradigm in e-health solutions through the VIRTUS middleware

Marco Bazzani, Davide Conzon, Andrea Scalera, Maurizio A. Spirito

ISMB – Istituto Superiore Mario Boella Turin, Italy

{bazzani,conzon,scalera,spirito}@ismb.it

Claudia Irene Trainito ENS – École normale Supèrieure de Cachan

Paris, France trainito.claudiairene@gmail.com

Abstract— In Europe, in a context of growing population and decreasing resources, ageing related diseases represent one of the most relevant challenges in terms of healthcare organization complexity, plus care levels and system financing balancing. Nowadays there are several researches that are studying the application of the IoT (Internet of Things) paradigm in the e-health field. This paper explains how a solution, built on the top of the VIRTUS IoT middleware, provides a valid alternative to current IoT solutions, which are mainly based on SOA (Service Oriented Architecture). VIRTUS leverage an Instant Messaging protocol (XMPP) to guarantee a (near) real-time, secure and reliable communication channel among heterogeneous devices. The presented development has been exploited in a healthcare case study: an implementation of a cost-savvy remote body movement monitoring system, aimed at classify daily patients’ activities, designed as a modular architecture and deployed in a large scale scenario. The paper analyzes the features offered by the VIRTUS middleware, if used within a e-health solution, providing a comparison with other well-known systems. Keywords-component; Internet of Things, e-health, telemonitoring, VIRTUS Middleware, XMPP.

I. INTRODUCTION Recent demographic studies have shown that the increase of aged people with chronic diseases will lead to an increasing demand for support services. Thus, importance to define new models for healthcare, in order to take attention not only on treating of diseases, but also on continuity of care and prevention at different levels. This need led to the development of several e-health solutions (details in section II.A) and then to the introduction of the Internet of Things (IoT) paradigm in these systems (sections II.B and II.C).

Recent ICT technologies offer the possibility to monitor patient's activity independently and automatically, by opening new opportunity in the field of remote monitoring. In fact, taking advantage of the new IoT paradigm and body area networks technologies, it is possible to classify patient’s daily activities directly at their home.

The IoT paradigm has been defined as an evolution of the current Internet ([1], [2]), which enables devices to interact each other using open standards and providing pervasive services. E-health is one of the application scenarios in which this paradigm has been applied, as well as energy monitoring or industrial applications.

Currently, the IoT concept is associated with the introduction of an architectural layer that integrates the data provided from many heterogeneous sources (for hardware and software architecture and for communication protocol used). This architectural layer is called “middleware” and, besides the integration of data, is also involved in many other IoT aspects (from networking and communication to context management).

After an analysis of the general requirements of an e-health IoT solution and of the current IoT e-health systems (sections II.D and II.E), this paper, in section III, introduces VIRTUS, an event-driven middleware, which bases its architecture mainly on the standards XMPP (eXtensible Messaging and Presence Protocol) [3] and OSGi (Open Service Gateway initiative) [4], to support IoT applications.

In section V the features provided by an e-health solution that leverages VIRTUS are compared with those given by other current researches and developments.

Section V presents the practical case study which has covered the definition and development of a remote motion rehabilitation solution.

Finally in section VI there are the authors’ conclusions. This paper doesn’t show the results of a medical validation for the algorithms or the procedures used in the field trials. The work intends to demonstrate how an open, flexible and IoT platform, as VIRTUS, could support a scientific field trial with a large number of users within an e-health scenario.

II. E-HEALTH AND IOT

A. Traditional e-health solutions In the last years, the telemedicine science had a

significant growth, several scientific papers were published and many projects were done, some of them becoming commercial products, used on a large scale.

Several EU projects have studied or are still studying e-health problems and possible solutions. The proposed solutions involve the development of platforms for home care, capable to bring health care into patients’ home in order to monitor their hospitalization [5], other research

This article is part of the work carried out within the regional project “Piattaforma Tecnologica Innovativa per l’Internet of Things”, co-funded by the Regione Piemonte (2009-2012).

2012 IEEE 11th International Conference on Trust, Security and Privacy in Computing and Communications

978-0-7695-4745-9/12 $26.00 © 2012 IEEE

DOI 10.1109/TrustCom.2012.144

1954

projects have focused their work on systems for remote surveillance to assist and foster the independence of elderly people [6]. All the issues related to support services have been studied, such as, the safety of the elderly, the possible loss of sensorial faculties, privacy and data integrity of each elderly person. In all the studies proposed is always expected an operations center for alarm management and continuous monitoring of patients.

More recent projects have covered the field of Ambient Assisted Living (AAL). Areas involved are the telecommunications, computing, nanotechnologies, microsystems, robotics and new materials. Purpose of these studies is the development and use of these new technologies to allow elderly and disabled to live comfortably at home, improving their autonomy, facilitating daily activities, ensuring good security, monitoring and treating sick people. The widespread use of AAL applications might avoid admissions to hospitals or nursing homes, in many cases, allowing a better quality of life for the patients and savings for the community.

Other solutions were developed and commercialized by private companies. These services were thought to support all moments of patient "medical life", to collect data, to monitor health status and to act on prevention and medical care, instead of on emergency. Products used to achieve this goal can be electronic health records or services for remote monitoring of biomedical data.

Extremely interesting are wireless solutions for healthcare, which provide tools to control, monitor and manage standard users’ health and patients with serious or chronicle diseases, using advanced technologies (Bluetooth, Internet, Wi-Fi, GPRS).

The remote monitoring is made possible by using different biomedical devices, they measure and transmit data via Bluetooth or ZigBee to a unit that manages them (PC, iTV). The collected information may be stored on the device or sent to a collection center that provides a complete monitoring, for both health professionals and patients. Access to the medical center can be allowed, via web, from mobile device or PC ([7], [8], [9] and [10]).

B. Leverage the IoT for e-health solutions As indicated in the introduction, in recent years, have

been analyzed the advantages of the introduction of the IoT paradigm, especially using a middleware, in the existing solutions. In this particular field, a role of a middleware is to obtain continuous communication among different devices, using communication channels characterized by heterogeneity and often unreliability. Furthermore, in particular cases like mobile-health solutions, the connectivity could be intermittent, due to mobility or interference. Middleware are used to ensure interoperability among several different devices and applications: medical instruments, body and environmental sensors, logic applications, graphic interfaces. This objective is obtained using open technologies, like XML and web services. Other

two important roles of these middleware are to guarantee scalability for the solution and to ensure easy integration of new devices, also after the release of a product. Finally, middleware must ensure security and privacy for the data, both when is collected and stored by the devices, and when is exchanged among middleware entities, also over internet.

Nowadays, the introduction of IoT in e-health has been simplified, because a standard communication protocol, wired and wireless, had been added on medical devices. In addition, many manufacturers of biomedical devices, in order to encourage the IoT use in medicine, are releasing all the necessary APIs to interact with their products, allowing in this way further customizations.

C. State of the art (e-health IoT solutions) As seen previously, the application of the IoT paradigm

to the health field can provide several benefits and several resulting applications: in such area, can be mentioned tracking objects, medical staff and patient identification, authentication of people and automatic data collection. A large number of projects were created around these activities and this technology became an important part of the health sector, especially for important results reached.

As concern prevention and detection of emergency situations, systems are used to data-fusion, using different heterogeneous data such as geographical position, movements study by using gyroscopes, audio and video data, acceleration sensors and measurement of pressure and heart rate. With these techniques, it is possible to predict dangerous situations and intervene immediately and properly [11]. The automatic data collection and transfer is useful to reduce response time, in case of illness and, in a broader context, to prevent potentially dangerous situations.

Another enabling technology, for the collection and processing of data is the Radio Frequency Identification (RFId) [12]. In the e-health field this technology can be used for identification of the patient, to reduce accidents such as the administration of a wrong drug or a wrong dose, or for children identification to prevent the case in which children are not properly identified and put in the wrong cradle. It can also be used for tracking of biomedical equipments inside the hospital in order to facilitate their identification and localization, to improve the workflow and to be more efficient in case of maintenance and monitoring [13].

D. E-health Requirements From the analysis of the state-of-the-art has been

identified a list of general features typical of e-health IoT solutions, schematically shown in Fig.1.

Figure 1 - e-health features

1955

Beyond these, have been derived a series of basic requirements for an IoT middleware, to be suitable for e-health solutions. The general requirements concern mainly the management of data produced by many heterogeneous devices (body sensors, wired and wireless medical instruments, and so on), regardless of their position. Other minor requirements are connected to the differences in the way in which these devices represent their data, influencing many aspects, such as communication protocols, and security requirements. Moreover, there are also some application-oriented needs: the architecture must be scalable, to support a high number of patients; (near) real-time communication must be provided, especially for “alarm features”; open technologies and standards must be used to facilitate lower prices for products based on this platform; finally it’s necessary the possibility to compose solutions with only the needed modules, to promote the reuse of the same platform in different scenarios.

The requirements concerned with e-health security and privacy aspects are: the ability to authenticate every single sensor, producer of data; access control to the resources and data integrity, to ensure to avoid data manipulation both when the data are stored in unattended sensors (protecting the sensor memory) and during the communications (through cryptography mechanism); it must be ensured that the health data of the patients are available only for authorized people (relatives and caregivers); and, finally, the data must be stored only until is absolutely needed.

E. Current existing solutions Nowadays, many middleware solutions for Internet of

Things have been developed, as the result of different research projects, but only a few of them, designed to be general purpose, are suitable to be used also in the e-health scenario; for this reason, middleware like UBIWARE, UBIROAD, Aspire and WhereX are excluded from this analysis, because designed only for one specific scenario.

Linksmart [14] (formerly known as Hydra) is a general purpose middleware based on a Service Oriented Architecture. As indicated in [15] the middleware has already been tested in the e-health field as an instrument to allow the easy integration of heterogeneous devices in one solution. The SAI middleware [16] uses the SOA principles for the integration of embedded devices with services, enabling the development of context-aware applications. In [17] is described the use of this middleware for an e-health care solution. Another two middleware, tested in this field, are SMEPP [18] and Plastic [19], both used by Telefonica to build a pervasive e-health platform. The SMEPP project has developed a middleware based on an abstract model for Embedded Peer-to-Peer systems (EP2P). The Plastic Middleware empowers the traditional SOA, enabling lightweight services to be run on mobile nodes.

Finally there are several other solutions that don’t have already concrete examples of use in this field, but that, for their features, can be certainly used in the e-health scenario: SOCRADES [20] uses SOA to interconnect a wide range of networked devices; Sensor Andrew is a project of the Carnegie Mellon University that uses the XMPP protocol

(particularly its publish-subscribe architecture) to host many different sensors and actuators. Global Sensor Network [21] is a middleware for rapid deployment and integration of heterogeneous wireless sensor networks, which provides a virtual sensor abstraction to enable the user to declaratively specify XML-based deployment.

Analyzing the current solutions, the authors have noted that the most of them use similar Service Oriented Architectures and that would be interesting try to build an alternative solution using the VIRTUS Middleware.

The architecture of VIRTUS leverages on: Java for the core of the solution, to make it easily portable to all the platforms that support this programming language; OSGi (via Knopflerfish [22]) to support modular and dynamic solutions; the XMPP instant messaging protocol, for a near real-time and high scalable communication; wide range of heterogeneous sensors and actuators (e.g. in the e-health field, for the detection of several vital signs and environmental parameters).

In the next two sections will be presented the details of this architecture and the differences with a traditional SOA.

III. THE VIRTUS MIDDLEWARE ARCHITECTURE Using one of the most accepted classification for

middleware [23], VIRTUS is a publish/subscribe middleware, but leveraging on its architecture, this solution overcomes all the problems typically recognized in this type of solutions. The use of XMPP, instead of other traditional protocols like JMS, allows the entities of the system to know if a message is arrived to destination and, furthermore, if a subscriber is offline when the messages are sent (leveraging the XMPP presence system). This last feature is important if the receiver MUST receive the message.

XMPP has been chosen to realize the communication near-real time, secure and scalable, needed for an IoT solution, analyzing the major massaging protocols currently available, such as SIMPLE, JMS, IMPS. SIMPLE is an IETF “open” protocol. It’s an extension of SIP (Session Initiation Protocol), that adds to the traditional VOIP protocol (Voice Over IP) some features typical of Instant Messaging. The limits of SIMPLE are: the use of proprietary extensions to support message-oriented features, not defined in the original standard; and the use not only of TCP but also of UDP as transmission protocol. JMS is part of the platform JEE (Java Enterprise Edition), used to send messages from one client to many others. It’s used to enable components of distributed applications to communicate each other, in a loose coupled, reliable and asynchronous way. In a world of heterogeneous devices this solution has the limit to be absolutely linked to Java. IMPS is an instance messaging protocol designed for mobile device, defined by OMA (Open Mobile Alliance). It is a solution widely distributed and tested on different platforms, but rarely used, for its limits, compared to other clients available.

XMPP (originally known as Jabber) is a real-time messaging protocol open and based on XML. The basic features of the protocol are: the exchange of messages, presence information and events and in general the routing of XML. This technology, designed between 1998 and 2004, is

1956

still stable and is constantly enriched with new features, thanks to its active community of developers. XMPP offers a number of advantages over others protocols. It's an open-source protocol and thus is free and open; this aspect is important to limit the cost of a solution based on its standard. The core of XMPP is a mature technology used by millions of users to communicate e.g. with Google Talk. XMPP has intrinsic mechanisms for the security: every XMPP server can be isolated from the public network (because it’s a fully decentralized protocol, in which every server can manage its own network), and security can be enforced through protocols such as SASL (Simple Authentication and Security Layer) and TLS (Transport Layer Security). Finally, through the use of XML the developers can add their personal features to XMPP.

The VIRTUS architecture leverages XMPP to obtain a seamless communication layer to support its operations and adopt OSGi as a reference framework to achieve the desired modularity. OSGi technology is a system to manage dynamically the life-cycle of Java based software and allows applications to be composed by relative small and highly reusable modules. In VIRTUS, this framework has been exploited to allow changing the composition of modules dynamically at runtime, without restarting the entire environment. Indeed, all the sensors, algorithms and user interfaces have been developed as modules and, in this way, it’s possible to build many different customization of the middleware using different compositions of the same modules. Thanks to this feature, the middleware is suitable to different application scenarios (e.g. for checking energy consumption of a house, monitoring health of a patient, tracing movement of goods within a warehouse, etc.).

In VIRTUS, each module (bundle) is identified univocally with an XMPP account. This account is used to know other modules availability (leveraging on the presence mechanism) and to communicate with other bundles.

For scalability reasons, the OSGi methods for communication (based on Service Registry) were not considered appropriate for IoT applications and only the protocol XMPP has been used for the communication among the modules. In particular, the following XMPP communication messages have been used to design the Middleware communication protocol: <Message/> stanza, InfoQuery (or <IQ/>) stanza and <Presence/> [24].

Furthermore, also some XMPP Extension Protocols (XEPs) [25] are the basis of the VIRTUS architecture. The Ad-Hoc Commands (XEP-0050) provide workflow capabilities for any structured interaction between two XMPP entities, allowing one entity to request completion of the commands to another entity, also receiving results using the Data Forms (XEP-0004). Service Discovery (XEP-0030) is used to discover what entities are on the network and which XMPP features, they implement. Publish-Subscribe paradigm (XEP-0060): enables the decoupling among senders and receivers of the data. The sender publishes the events on an information node, ignoring who receive those events; the receiver can subscribe itself to that node and then will receive a notification when a new item is published on the node. Another important feature of this paradigm is that,

if the receiver is not online, when the data it’s published, it can retrieve the data from the node, when it returns online; this is important in the e-health field, where vital data must not be lost also in case of poor connectivity.

An instance of VIRTUS is composed by three “core” modules and further “application-specific” bundles. One of the basic module is the XMPP server. VIRTUS has been tested with the Openfire [26] XMPP server, one of the most reliable and scalable [27] open-source real time collaboration (RTC) server, among those available on the market. Another core module is the Manager, able to connect appropriately the different modules in a middleware instance. It enables a module to receive a list of available modules (filtering by the module needs) in an instance and allows a bundle to update its own dependences. The last core bundle is the Gateway, which acts as an interface to any external software that requires communication with local instance (also with other instances of VIRTUS). It’s the unique point of contact between the inside and the outside of a middleware instance. For this reason, it’s the only module that has two accounts: one on the local XMPP server for the interaction with the modules of the instance and one on a public XMPP server to communicate with other gateways, to enable inter-domain communications. Finally, there are other “application-specific” modules, that can be used to drive a sensor (e.g. environmental sensors, medical devices, and so on), to implement ad-hoc application logic (e.g. to compare data with threshold values and to trigger alarms automatically, if the value is outside the normal range), to connect to databases, or to show (also web-based) GUI, etc.

Figure 2 - Virtus Architecture Layers

Figure 3 - Virtus Modules

1957

VIRTUS architecture addresses three types of devices: resource reach devices (like PC), that can host the entire SW architecture (OSGi, XMPP Server, SW modules); resource poor devices (like smartphone), which use XMPP client library to connect to the XMPP Server, for the interaction with other bundles; and, simple devices (like sensors) that use a “driver module”, hosted on a device of a type of those described above, to encapsulate their data in an XMPP message. This is suitable for Bluetooth and ZigBee devices as for IoT platforms as Contiki [28] and TinyOS [29].

To preserve interoperability with other widespread solutions, (aspect very important in the world of distribute applications) mechanisms have been developed to allow VIRTUS bundles to exchange data with modules of platforms that use different communication protocols than XMPP (e.g. web service for SOA). For example, some VIRTUS bundles have been enabled to work with modules of the Reply’s web-service based middleware [30].

The VIRTUS development, based on previous research works ([31], [32]), has been already employed in practical application scenarios [33] and is objective of current national (“Piattaforma Tecnologica Innovativa per l’Internet of Things”) and international research projects [34].

IV. COMPARISON OF MIDDLEWARE ARCHITECTURES Comparing the features provided by VIRTUS with those of a traditional SOA, some differences can be highlighted. Some features, like security and service discovery, are built-in function of the standard communication protocol in VIRTUS, instead require the use of some particular additional protocol in the SOA. The publish-subscribe paradigm provides a scalable, real-time and asynchronous model of communication, different from the request-response paradigm typical of web-based applications. For naming and addressability, SOA is based on static IP addresses, instead VIRTUS uses dynamic XMPP accounts, in this way a resource can be addressed regardless of its position. Both the solutions are based on modular and reusable components, the services in the SOA, the bundles in VIRTUS. Both the architectures are scalable: VIRTUS, thanks to the features of the XMPP protocol, the traditional SOA, for the introduction of the concept of cloud computing. If one module is upgraded frequently, in SOA it’s more simple guarantee that the entire system is always up-to-date, because there’s an only centralized copy of the software, instead in VIRTUS there are many different copies, that must be upgraded simultaneously. Finally, SOA is the natural choice to allow many users to collectivity interact with the same data and since the data are centralized, the customer doesn’t need to worry about the possibility to lose the data due to a local hardware malfunction or due to the loss of the whole device (e.g a smartphone). These problems are addressed also in VIRTUS, using modules with a public web interface and storing the data remotely, but require specific developments and are not an integral part of the solution.

In conclusion, the authors have identified VIRTUS as a good alternative to the traditional Service Oriented Architectures, that can be used also in the IoT e-health field.

V. CASE STUDY

A. Current e-health system The solution, proposed to demonstrate the use of the Internet of Things applied to the activity of monitoring, is based on a system able to classify the movements of patients, who received rehabilitation. The system is essentially composed by four subsystems: 1) wearable devices, to collect data concerning patient activity and send them to the gateway. Wearable monitoring sensors measure some parameters of the movement, in particularly the changing of the posture. This information is detected from the analysis of data from two sensors integrated with a triaxial accelerometer, placed one on the belt and one on a knee. These devices are cheaper than the equipment used in a standard laboratory, can be used not only in a laboratory environment, and enable a non-invasive classification of daily activities thanks to their small size. 2) Middleware. The software layer that enables the interconnection among the system modules. 3) SmartDevice (smartphone or PDA) is the interface between the users, the system and the remote center. In order to ensure a non-invasive system, it has been decided to use a common smartphone. It receives data from the devices, processes the classification in real time, showing also the results to the patient. After have inserted the data in an XML format, it is also able to communicate with the “project management software” using the XMPP communication, offered by VIRTUS. Furthermore, the SmartDevice, can give to the patient information on the status of the system and bio-feedbacks on his/her activities (from the Central Unit). 4) Central Unit or project manager software, receives raw-data and data classified from the SmartDevice, it processes more accurately them and it provides a daily report with all information useful for physician in order to do evaluation and diagnosis. It also generates feedback available for patient. The system allows to accurately monitor the patient's motion, recognizing postures and counting the number of steps taken during the day. From daily reports, it is possible to extract objective information and data of interest, it can be studied how a patient reacts, on a motor point of view, after administration of drug; it can be evaluated the time required between the end of activity and the beginning of the next one; the patient could be motivated to perform exercises precisely because they will be evaluated by specialists.

Figure 4 - Case Study Architecture

1958

VIRTUS provides to the system a reliable, scalable and secure communication channel. In fact, through XMPP, the data are exchanged safely also over internet and there are not data loss, also in case of poor connectivity (leveraging the features offered by the publish/subscribe paradigm). Although the system is already available, for a large scale testing, this does not exclude the possibility of improvements in both software and hardware system, to implement a complete telemonitoring solution.

B. Possibile system improvements Leveraging on the features of VIRTUS will be possible

to develop a complete telemonitoring suite that adds to the system described in the previous section, the possibility of monitoring the patients' health condition, through their vital signs. In particular, integrated in VIRTUS there are already: a blood pressure monitor, a glucometer, a thermometer and an oxy-pulsimeter (all Bluetooth devices) and, in the near future, also other two wireless devices will be integrated: ECG and chest belt, and others could be added later. Also if all the devices have a different proprietary communication protocol, they can be used in a common solution, using for each a VIRTUS driver module, that encapsulates the data provided, in standard XMPP messages.

Furthermore, for every patient will be installed a customized version of the system, only with the modules that drive the electromedical devices useful for his type of pathology, it will be possible to add or remove modules (also not already developed, when the system was deployed the first time) easily, without restarting the entire system.

VI. CONCLUSION The paper has discussed the motivation that has led to the

introduction of the IoT paradigm in e-health. Then the VIRTUS middleware has been presented, and finally has been analyzed one concrete use of VIRTUS in an e-health solution, stressing the advantages provided by its use in this scenario.

REFERENCES [1] Ovidiu Vermesan, Peter Friess, Patrick Guillemin, Sergio Gusmeroli,

Harald Sundmaeker, et al., Internet of Things Strategic Research Roadmap. s.l., European Commission, 2009.

[2] Cooperating Objects NoE. Research Roadmap on Cooperating Objects. Bruxelles : European Commission, 2009.

[3] XMPP Standards Foundation. XMPP. [Online] http://xmpp.org/. [4] OSGi Alliance. OSGi main. [Online] http://www.osgi.org/. [5] PROJECT TOPCARE [online].

http://cordis.europa.eu/projects/54831_en.html [6] PROJECT TELECARE [online]. http://www.ist-

world.org/ProjectDetails.aspx?ProjectId=e026dfb7cae044b58d5cad6eb3521a9e

[7] IEEE 802.15 WPANTM Task Group 6 (TG6) Body Area Networks,http://www.ieee802.org/15/pub/TG6.html.

[8] Sana Ullah, Henry Higgins, Bart Braem, Benoit Latre, Chris Blondia, et al., ’A Comprehensive Sur- vey of Wireless Body Area Networks’, on PHY, MAC, and Network Layers Solutions, Journal of Medical Systems (Springer), 2010. DOI: 10.1007/s10916-010-9571-3.

[9] Body Area Networks: A Survey. Mobile Networks and Applications (MONET) (Springer Netherlands).

[10] Schmidt R, Norgall T, Mörsdorf J, Bernhard J, von der Grün T. (2002), Body Area Network BAN–a key infrastructure element for patient-centered medical applications, Biomed Tech.

[11] Istepanian, R S H, Hu, S, Philip, N Y, Sungoor, A. The potential of Internet of m-health Things "m-IoT" for non-invasive glucose level sensing. 33rd Annual International Conference of the IEEE EMBS Boston, Massachusetts USA, August 30 - September 3, 2011.

[12] Frederix, Ines. Internet of Things and Radio Frequency Identification in care taking , facts and privacy challenges. University of Hasselt Diepenbeek, Belgium.

[13] PROJECT BUTLER[online]. http://cordis.europa.eu/search/index.cfm?fuseaction=proj.document&PJ_RCN=12437244

[14] Linksmart. Project Linksmart. [Online] http://www.hydramiddleware.eu/news.php.

[15] Jahn, M. and Pramudianto, F. and Al-Akkad, A.-A.(2009) Hydra middleware for developing pervasive systems: A case study in the eHealth domain

[16] David Parlanti, Federica Paganelli, Dino Giuli and Agostino Longo. A Scalable Grid and Service-Oriented Middleware for Distributed Heterogeneous Data and System Integration in Context-Awareness-Oriented Domains. The Internet of Things - part 2. 2010.

[17] Federica Paganelli, David Parlanti , Dino Giuli, A Service-Oriented Framework for Distributed Heterogeneous Data and System Integration for Continuous Care Networks, CCNC 2010 7th IEEE, 9-12 Jan. 2010

[18] SMEPP. SMEPP : Secure Middleware for embedded peer to Peer Systems. [Online] http://cordis.europa.eu/fetch?CALLER=PROJ_ICT&ACTION=D&CAT=PROJ&RCN=80125.

[19] Plastic. Plastic Middleware [Online] http://plastic.paris-rocquencourt.inria.fr/the-plastic-middleware

[20] SOCRADES Project. SOCRADES Project. [Online] http://www.socrades.eu/Home/default.html.

[21] Global Sensor Network. Global Sensor Network. [Online] http://sourceforge.net/apps/trac/gsn/wiki.

[22] Knopflerfiish [online] http://www.knopflerfish.org/ [23] Hurwitz, J. Sorting Out Middleware. DBMS magazine 11.1, January,

1998. [24] Peter Saint-Andre, Kevin Smith, and Remko Tronçon. XMPP: The

Definitive Guide. 2009. [25] XMPP Standards Foundation. XEPs [Online] http://xmpp.org/xmpp-

protocols/xmpp-extensions/ [26] Ignite Realtime. Openfire Project. [Online]

http://www.igniterealtime.org/projects/openfire/index.jsp. [27] Ignite Realtime. Openfire Scalability [online]

http://www.igniterealtime.org/about/OpenfireScalability.pdf [28] Contiki [online] http://www.contiki-os.org/ [29] tinyOS [online] http://www.tinyos.net/ [30] Reply, The Reply Research and Development centre for the Internet

of Things [Online] http://www.reply.it/en/practices/iot/ [31] Claudio Pastrone, Maurizio A. Spirito, Riccardo Tomasi, Federico

Rizzo. A Jabber-Based Management Framework for Heterogeneous Sensor. International Journal of Software Engineering and Its Applications. July, 2008.

[32] Fabio Forno, Antonio Sciarappa. RFID in the Internet of Things: from Static to the Real-Time. RFIDDays 08 Proceedings. s.l. : G. Marrocco editor, 2008.

[33] Brizzi, P., Lotito, A., Ferrera, E.,, Conzon, D., Tomasi, R., Spirito, A., M., “Enhancing traceability and industrial process automation through the VIRTUS middleware”, Middleware ‘11, December 2011

[34] PROJECT PIGWISE [online] http://www.pigwise.eu/index.html

1959