On Developing a Novel Versatile Framework for Heterogeneous Home Monitoring WSN networks

The ability to deploy efficient and versatile WSN networks in the home environment is and will remain in the years to come a cornerstone objective in wireless networking. Respective services are continuously expanding requiring novel design and implementation approaches able to cover all relative present and even more importantly future requirements. This paper aims to present and convey knowledge and experience gained from such an effort in the context of home monitoring. Respective discussion covers all relative aspects and analyzes all critical challenges addressed ranging from identification and specification of the main requirements, to possible implementation approaches considered and finally the actual development undertaken. The final outcome considering the WSN home monitoring infrastructure as well as extracted knowledge and practical conclusions can be proven useful for further extending such an endeavour or even pursuing a different


Introduction
Nowadays it is commonly accepted that in the near future, novel approaches able to cover all aspects of home environment monitoring will constitute a key necessity.Various reasons advocate relative views including several studies concerning the population's everyday life characteristics, in conjunction with the high interest home monitoring receives both from academia as well as industry [1,2,3,4].In light of these challenges, Ambient Assisted Living (AAL) consists a fundamental research domain that has drawn massive attention.Rather than being a technology itself, AAL encompasses embedded networked devices and sensors, algorithms and diverse ICT technologies to support people in their preferred environment.AAL environments are mainly applied to promote a healthier lifestyle, to enhance life quality of elder and/or handicapped people and to support their families and caregivers in an unobtrusive way.In this context, novel approaches are required to offer respective services characterized by minimum intrusion thus yielding significant added value of allowing the person to be self-reliant and independent.From another perspective, home environment monitoring can go beyond the human factor and focus on a wide range of characteristics of the environment itself.In that sense, security, surveillance, energy consumption and remote access comprise areas attracting increasing interest.Additionally, in many cases people tend to spend significant part of each day away from home.Consequently, a home monitoring system able to detect intrusions or even aspects compromising safety and security (i.e. a window/door left open, the oven is left on etc.) could be an invaluable tool [5,6].Furthermore, accurate power consumption monitoring in the context of minimization of power wastage or even energy demandresponse programs support [7,8] also comprises a significant objective.However, all the above capabilities can become a reality only through the significant advancements in the fields of Wireless Sensor Networks (WSN) regarding ultra low power consumption embedded systems and miniaturization [9,10].Indeed over the last years both the number of available WSN platforms offering different capabilities as well as the range of different sensor support continuously increases moving towards a holistic home environment platform.Despite the increased number of choices being available, heterogeneous approaches remain still a critical challenge prohibiting a unified operation [11,12].Driven by this observation, this paper presents a framework under which heterogeneous platforms supporting different and diverse sensors can coexist.Thus such a platform offers a truly comprehensive, flexible and extendible solution.In this context, all steps from initial requirement definition to respective undertaken implementation are analyzed and discussed.The rest of the paper is structured as follows: Section 2 analyzes critical requirements comprising the guidelines for design and implementation decisions.Section 3 focuses on solutions considered as the basis of the final implementation, while section 4 presents specific implementation details and challenges addressed.Finally, section 5 presents the main conclusions and future extensions.

Requirements
In order to offer an efficient platform the first critical step is the accurate definition of related requirements.As seen in Figure 1, the overall platform is divided into three segments.The first one relates to the different sensors supported, the second one focuses on the wireless communication technologies, software stack and interfaces while the third includes the home gateway and service delivery platform able to efficiently receive data, store and process them as well as convey them outside the home environment whenever required.High level harmonization of these segments is crucial towards an efficient platform, both in terms of behaviour and performance.

Figure 1. High Level system architecture of a Home
Environment Monitoring platform

Wireless Sensor Communication Environment
Aiming to offer a useful and practical home environment monitoring system, the WSN design comprises a crucial point since it entails most of the features as well as challenges that must be addressed.Probably the single most important aspect of such a network stems from the fact that is going to be installed in the user's private home area.Such an aspect is by itself a very sensitive issue and handles potentially highly sensitive data at any given time.So, in order to be well accepted, it is of high importance to be non-intrusive and to avoid causing any kind of discomfort to the end user [13,14].The specific objective is even more challenging when considering sensors that are worn and must be at direct and constant contact with the user.
In the context of the system envisioned, a comprehensive system should monitor a wide range of diverse signals including physiological, ambient and kinetic [15].At the same time, such a system should be flexible, extendible and open source so as to embrace, integrate and cooperate with novel technologies that are bound to be available in the near future [16].
During the last few years, state of the art WSN technologies exhibit impressive advances advocating respective system as a prominent base upon which a home monitoring platform can be developed.On one hand, advances in hardware design, integrated embedded systems and miniaturization have proven that extremely small, yet sufficiently powerful devices can be implemented.Additionally, such devices offer the capabilities to acquire data from the physical world, store and process them, but even importantly wirelessly transmit them using embedded transceivers.On the other hand, software developments have introduced a completely new communication paradigm attracting high interest both from academia as well as industry [17,18].

Development Environment:
Software stack comprises the structure effectively hosting protocols and algorithms enabling WSN nodes to offer the required functionality in the context of a specific WSN network.On top of the communication platform, a wide range of complex algorithms implementing the respective intelligence must be effectively developed.From a communication point of view respective algorithms may include routing, transport, application and middleware protocols that must be supported or developed.Even more, user algorithms for data pre-processing, compression, event detection, security etc. are increasingly required by many demanding applications.All these requirements must be provided by a flexible, extendible and efficient software development environment.Moreover, adequate operating systems enabling synchronization, multitasking, shared memories and many other features typically found in highly efficient computer systems are also required.An optimum selection in this context also facilitates heterogeneity and support of new technologies.

Processing Capabilities and Energy Availability:
Of course none of the above requirements can be met without adequate processing capabilities being offered by the main WSN node-processing module.However, trying to minimize the size, the cost, the complexity and the power consumption leads to very low energy modules, usually of simple architectures, at clock frequencies of few tens of MHz and scarce memory availability.As a result, highly efficient programming is required.At the same time, advanced processing capabilities regarding either data processing or communication demand adequate energy availability, which probably creates the most challenging trade off.

Sensors:
From the previous section it is clear that if a successful home environment monitoring system is targeted, the selection of the optimum set of sensors is a prerequisite.Sensors must be integrated in home environment, or even more challenging in direct contact with the user for extended period of time.Therefore, the size and the design of the sensors are critical in order to be well accepted from a wide range of users including persons with chronic diseases, elderly people and other sensitive user categories.The number of the sensors deployed also plays a critical role so as to avoid the feeling of being constantly under surveillance and of not being independent.Thus, multiple sensors integrated into one WSN node is also a significant requirement.

Home Service Delivery Platform
The Service Delivery Platform (SDP) as depicted in Figure 1 aims at providing the infrastructure to ensure the communication among system components and provide intelligent information handling the delivery of a set of assistive services at the home data aggregation site.The user requirement analysis reveals several aspects concerning the design and development of the SDP, for the system to better meet user needs and expectations.These aspects can be further combined with valuable experience in the field of AAL systems and with a review of associated literature [19,20,21] so as to identify the respective challenges the SDP should address.As already indicated, most modern systems have an inherent heterogeneity as they employ various subsystems, access devices hosting user interfaces, sensors and WSN platforms provided by different manufacturers.In addition, there exist diverse data sources that provide heterogeneous information that needs to be processed appropriately.Therefore, interoperability is an important feature in order to enable smooth communication and interaction between both hardware and software components throughout the system.Thus, the SDP should employ appropriate infrastructural technologies for interoperable integration of access, sensing and actuating devices, as well as information modelling using knowledge representation techniques to describe information in a semantic level and create a unified vocabulary for all system components.Due to the highly dynamic nature of user needs and requirements that often change over time, the SDP should be flexible so as support transparent extension by appropriate services addition that best reflect the users' evolving demands.Towards this direction, a feature of great importance concerns scalability, as the SDP must support addition or removal of sensing devices in a seamless fashion without affecting the overall system behaviour.This also requires an open and standardized development approach for supporting the integration of components and services offered by third party providers through concrete APIs.Another important factor relates to adaptation at system and service level.Concerning the system level adaptation, the SDP must monitor itself and perform appropriate actions in specific cases, such as component or power supply failures.Likewise, the SDP should implement intelligent mechanisms to tailor the offered services to the current user status, environment, needs and preferences.Service personalization comprising a cornerstone feature has two aspects in the context of the proposed platform: service content and means of presentation.Personalized service content should consider data fusion of sensor readings, user profile information and lists of available services, while personalized presentation should mainly utilize information related to user preferences (described in user profiles), network resources and capabilities of available access devices.User participation is also a fundamental aspect in such platforms and varies depending on each system's goals and end-users' requirements.In the literature there have been described systems that base the service delivery process on data implicitly acquired through monitoring the user and his environment without or with minimal user intervention.On the other hand, there exist systems that mainly rely on the feedback explicitly collected by the users in conjunction with implicit information aiming to provide more control to the user himself in service provisioning.However, reports on user participation do not reveal any major differences between these approaches regarding benefits to the users [22].Based on the user requirement analysis of the proposed system, a rather limited user involvement should be considered, focusing on initializing user profiles and providing feedback in reminder and notification services.Safety and security constitute critical requirements for the proposed SDP, which should apply non-intrusive user authentication techniques to foster user privacy.Health data are considered highly sensitive and mechanisms to guarantee their confidentiality have to be integrated.Affordability and usability are finally two key features that SDP should take under consideration.On one hand, the platform, the required resources and the services must be affordable by customers and an important contribution to this is made by adopting open development approaches.On the other hand, the platform must be easy in its use offering a positive user experience.

Design Approaches
Indicative to the appeal and high interest WSN home monitoring has attracted, is the wide range of different choices that are available regarding all design aspects of such endeavour.In that context, the main objective of this section is to present respective critical design choices adopted when designing and developing the proposed home environment monitoring system.

Wireless Sensor Network
The main objective of this section is to present several critical design choices considered and adopted throughout the process of designing and implementing the WSN component of the envisioned platform.The main axes driving the following selections are flexibility, heterogeneity, extensibility and meeting performance requirements of a wide range of realistic applications.The first aspect addressed concerns adequate selection of communication technology with minimum resource wastage.In order to meet such an objective with respect to the widely diverse acquired signals, it was decided that diverse prominent communication technologies should seamlessly be supported under a common framework offering a unified interface towards the end user.Specifically so as to maximize interoperability and heterogeneity support on one hand Bluetooth communication technology is selected as the most appropriate solution for relatively more demanding or/and time constrained data communications requiring QoS, minimum packet losses and sufficient guaranteed bandwidth [23].Indicative respective applications mainly focus on physiological signals like ECG, SpO2, blood pressure etc.Also kinetic related sensors could take advantage of such QoS support related to accelerometer, gyroscope and magnetometer signals.Bluetooth based communications comprise optimum solution when the wireless channel is to be shared by a high number of concurrently transmitting sensors [24].However, when lower demands are posed, respective solutions may lead to resource wastage concerning power consumption while requiring more complex and costly implementations.Such cases can include low traffic sensors like ambient monitoring signals such as temperature, atmospheric pressure, light sensors or even more demanding ones like the previously mentioned kinetic sensors.Consequently, in cases where data sampling occurs at very low frequency such as 1 Hz or even lower, our design offers seamless support of less complex solutions based on IEEE 802.15.4 [25] or ZigBee [26,27] which appear as an alternative offering ultra low power and low cost radio chips.However, the two aforementioned technologies address communication support from a completely different angle.Bluetooth follows a contention oriented approach when QoS is required indicating that transmitters and receivers are paired and specific connections are formed and maintained while communication is controlled by the central entity indicated as the master node.IEEE 802.15.4 follows a highly distributed communication approach where all nodes act as peers and no prior connections are required for a node to transmit data.Consequently, supporting both communication approaches under a common interface was a difficult challenge.However, presented platform effectively tackles such challenge offering high degree of interoperability and heterogeneity support as it will be depicted in following sections.The communication technology adopted represents only one of the main design components a system must take under consideration, as depicted in Figure 2. The processing capabilities constitute yet another critical aspect.Aiming to offer substantial performance characteristics of ultra low power functionality Texas Instruments (TI) and AVR represent two main players in WSN networks with a variety of Micro-Controller Units (MCUs) integrated in a wide range of different WSN node implementations.TI's MSP430 MCU comprises a widely used solution perfectly balancing processing capabilities and power aware operation for many different application scenarios [28], [29].The AVR solution is also based on RISC based MCUs typically offering higher performance capabilities and memory availability at the expense of high power consumption and less low power operation modes [30].Aiming to achieve optimal degree of interoperability our implementation has considered and been tested with sensors utilizing both TI and AVR based WSN nodes.Furthermore in order for any hardware component to reveal its advantages a suitable firmware is of outmost importance.Nowadays the selection of the appropriate WSN network is inherently correlated to the respective operating system, which comprises the heart of the software stack.In order to cover all possible scenarios, in this paper two state-of-the-art WSN OSs are considered as well as WSN nodes with no OS provision.The two prominent OSs are namely TinyOS [31,33] and Contiki [32].The former represents the most well-known open source environment and operating system upon which numerous dominant WSN platforms are based.Figure 3 illustrates a high level architecture of a TinyOS based software stack.Contiki-OS, on the other hand, is an open source Operating System (OS) for networked, memory-constrained devices based on an event-driven programming model.This aspect also comprised an interoperability cornerstone of the proposed design.Therefore, as it will be analyzed in following sections significant effort has been devoted so as to integrate both platforms supporting a specific WSN OS but also platforms where no specific OS is offered requiring a drastically programming paradigm.Last but not least prominent WSN platforms are integrated in the home environment monitoring platform such as Shimmer [34], e-Health [35] and TelosB based platforms [36,37].Thus the presented system is able to efficiently support and interoperate with a wide range of such platforms and even more cover all respective offered signal monitoring.Overall such characteristics enhancing interoperability capabilities of our platform are critical due to the non-intrusive nature of the platform which is of paramount importance towards a well-accepted system.

Ambient Assisted Living Middleware
The specific requirements of each ambient assisted living system demand a careful examination since they concern both home gateway and SDP components.In addition, besides the quality requirements mentioned in Section 2, there are multiple functional requirements as well, which need to be addressed through a combination of tools and technologies.The wide variations in abilities and needs of the elder population, their individual situations and their home settings, introduce high complexity in the scenarios Ambient Assisted Living (AAL) systems are called to fulfil.Therefore, customized solutions for individual cases and environments have to be implemented towards achieving an optimal result.To meet the aforementioned challenges, different approaches and technological solutions are proposed in the literature and are briefly described in the sequel.One of the predominant solutions is the OSGi service platform [38,39] that provides a Java based, serviceoriented, component-based framework for networked services.The main feature of this platform is the delivery of a common framework for all stakeholders to develop, integrate and administrate services to various settings in a coordinated manner thus maximizing the interoperability potential of respective developments.Each middleware component is developed in a bundle format publishing its services so that the functionality it provides can be utilized by other components.Every bundle is triggered when the service it has published is actually needed by another bundle.The framework can manage the dynamic installation and update of each bundle within the OSGi environment and enables a dynamic reconfiguration of services during runtime.Multi Agent Systems (MAS) constitute another widely used approach aiming to address distributed intelligent environments [40].In the context of software engineering an agent can be defined as "an entity within the environment of a computational system that is capable of flexible and autonomous actions, while complying to the objective goals for which it was designed" [41].
In addition, web-based platforms have been implemented focusing on an open and standardized approach for communication and interoperation of different software components.Using web services gives the ability to any AAL application to communicate with a given system's services, through SOAP and HTTP [42].
Apart from the aforementioned solutions, there are many other middlewares realized by other relevant approaches that aim at providing specific functionalities, services and applications by employing appropriate technologies.For instance, in [43] an Internet of Things based system is realized providing global connectivity and management of users, information and system component integrating advanced communication technologies, such as 6LoWPAN and RFID.Similarly, the Amigo Project [44] utilizes Universal Plug and Play (UPnP) as a core technology for communication and interaction between system hardware components, while supporting the service discovery and usage processes.Finally, ISO/IEEE 11073-20601, a standard attempting to promote interoperability among health devices, comprised a source of invaluable information to our effort.In the presented design the specific standard is not fully supported due to its close relation to specific communication profiles (e.g.HDP Bluetooth) effectively limiting the applicability of the presented approach as well as in order to avoid unnecessary complexity and potential communication related overhead [45].Moreover, we believe that our choice constitutes our platform more eligible for extension and experimentation by other research groups.

Platform Implementation
The main objective of this section is to highlight the main implementation aspects of the platform presented driven by previous requirements' and design analysis.

Ambient Intelligence platform
From the architectural perspective of the system the design principles of the Ambient Intelligence Platform (AIP) were defined based on modularity and extensibility as already have been highlighted.The AIP consists of two main components, the Home Gateway (HG) and the SDP.These two components along with their sub-components are depicted on Figure 4.

Home Gateway (HG)
A. HG Communication Module The much desired modularity and extensibility in the HG environment are realized as the capability to support seamless connectivity of existing and future heterogeneous devices so as to meet the current evolving trend of the wearable devices and sensors.This key requirement along with the rest, as already discussed in Section 2.2, constitute the main directives that formed the following functionalities: 1. Support for/of multiple network interfaces 2. Support for/of multiple types of sensors 3. Data aggregation and temporary storage capabilities 4. Data processing 5. User interface The HG is mainly responsible for collecting the data from a wide variety of diverse sensors and delivering them seamlessly to the SDP.This functionality can be briefly summarized as the interconnection of the sensor plane with the services plane.This functionality introduces the need for handling multiple communication processes.These processes are heterogeneous in terms of sensorial wireless technologies (Bluetooth, Zigbee) and transmission rates (high rate ECG streaming, low rate ambient temperatures updates).Apparently, in order to offer high degree of interoperability the communication drivers should satisfy all the individual networking demands for each sensing device and hide the implementation details from the upper layers of the application.Therefore, HG software is based on open source technologies with high degree of flexibility and adoption by the market as long as a large community of developers.Namely the software is developed with the Python programming language and run on the GNU/Linux operating system.The application communication protocol extends and enhances an open source application provided by Shimmer [34] that offers the interconnection with the Shimmer sensing devices and data monitoring.For our purposes we ported the respective logic to the context of the proposed HG platform, and extended it offering new capabilities so as to satisfy interoperability and heterogeneity support requirements.
Our application protocol has been heavily affected by The interaction between the health devices sensors ( agents according to the standard ) and HG ( manager ) can be summarized in the following three categories of commands: A. SET: Sensor configuration (enabling/disabling sensors, set sampling rate, calibration parameters) B. GET: Acquire sensing devices' configuration (sampling rates, sensor ranges, etc).C. ACTION: Starting and stopping the data streaming Those three sets, are a subset of the commands exchanged through a presentation layer packet, (Presentation APDU) according to the Standard.The HG for each command that sends to the sensors it receives a respective acknowledgement.Another critical cornerstone for the proposed system necessitated by the interoperability requirement is the introduction of the "sensing device's profile" concept, which was also inspired from the standard's classes of Medical Device System and Configuration.The scope of this extension is to deliver the support of heterogeneity which is one of the main impacts that the presented work introduces.Each sensing device is assigned with a node type id which is mapped to the respective vendor.This information is stored in a dedicated database table of the HG's storage space.The device's profile holds also information that further describes the sensor and is transmitted by the sensor itself after the reception of a GET type command sent by the HG.So far the node type id is the main feature that distinguishes different types of devices existing in the network.However the system should identify each sensing device even if they have identical configurations (e.g. two ambient temperature sensor devices of the same vendor).For that purpose an additional feature should further describe each device and that is the "unique id".
The fundamental element of the whole communication process is the data packet exchanged among the HG and each of the sensing devices.Table 1 presents the structure of an INQUIRY_RESPONSE packet where the greyed fields are the two new fields that indicate the particular source of each packet.

B. HG Communication Process
While idle, the HG listens for devices that follow the Serial Port Profile (SPP) through a respective background thread.SPP has been selected as a more generic profile, able to support both medical but also non medical data.This is in alignment with ADVENT platform envisioned as a system able to accommodate a wide range of data including health related, but also ambient or security related information [46].Furthermore SPP offers a wider range of applicability and support since it offers compatibility with devices not supporting HDP (which in various references is depicted as not as widely adopted as anticipated [47,48]or not offering anticipated advantages over SPP [49]).Finally, we feel that SPP is a more adequate selection targeting future Bluetooth versions (i.e.BLE) since transition to respective profiles will be much easier compared to HDP based developments.The HG interacts with the wireless devices through serial communication under a common approach independently of the actual communication technology supported (i.e.Bluetooth or IEEE 802.15.4.).Specifically RFCOMMx ports are employed when Bluetooth based devices are considered while ttyUSBx ports for IEEE 802.15.4 (for GNU/Linux systems).
As long as a device enters the vicinity of the HG's radio, the respective connection can be established.At the next stage the initialization takes place where HG and sensor exchange a sequence of packets.Specifically: 1. HG sends INQUIRY_COMMAND 2. Wireless Device (WD) replies with the INQUIRY_RESPONSE that announces to the HG its network wide unique ID and node type ID. 3. HG identifies the Vendor and the sensor set based on the node type id and the information that is stored at the respective mapping table 4. HG sends the start streaming command.
After that initialization stage the WD starts streaming acquired data packets.It is of great significance to mention, that the device profile carry all the information that the HG needs in order to define dynamically the length and the structure that each WD sends.Finally the last stage of the process passes to another important module, the Python parser, which is responsible to parse each data packet and extract the useful information.What is critical to emphasize is that this approach effectively offers a seamless approach regardless of the specific communication technology used or the specific sensor monitored.

Service Delivery Platform
Being responsible for the data handling, the respective functionality can be divided in many sub-tasks such as, the database transactions (inserts, selects, etc.), data processing (signals denoising/artifacts removal, health status assessment, fall detection algorithm, etc.) and decision-making (notify monitoring person, notify doctor, etc).Based on the existing approaches as presented in Section 3.2 and driven by the same concepts for modularity and extensibility, OSGI technology has been selected as the implementation approach of the SDP.In the context of the proposed system the addition and extension with a new device and new functionality e.g.adding an accelerometer device and a fall detection algorithm-from a simplistic point of view is realized as the implementation of two system modules.The first module is the communication driver responsible to notify the HG for its presence and deliver the desired connectivity and enable data collection.The second module is the OSGI bundle that implements the fall detection algorithm by processing the data fetched by the accelerometer device.Specifically, Figure 5 indicates some of the main functionalities of the SDP as being organized to the respective bundles.The bundles instantiate a set of OSGI services (delivered by the service registry), which are responsible for the collaboration and the communication among the bundles.

Wireless Sensor Network Architecture
In this section we highlight the main design and implementation issues addressed focusing on the WSN part of the home environment.

A. WSN Mote Firmware Application Layer
According to the envisioned platform a set of motes will be deployed to the personal area of a user.In general, their basic operations of a node will be: 1) data acquisition: sampling sensors, encapsulating measurements into logical packets and transmitting them to the Home Gateway, 2) Self-description: provide information concerning its configuration, 3) Control/ Reconfiguration: Control its operational mode through the HG or changing the values of its operation parameters in response to incoming commands.In order to achieve a flexible and extensible framework we should minimize the number of constraints imposed on selected motes.In order to meet the interoperability requirements our platform is able to integrate motes coming from different vendors, either with an RTOS such as Shimmer and TelosB platforms (TinyOS) or without one such as Arduino based platforms.Moreover our implementation should be able to support transparently the most widely used protocols for wireless communication i.e.Bluetooth and IEEE 802.15.4.Our software implementation is based on Shimmer's Boilerplate firmware [12].Specifically, we adopted the overall architecture as well as the provided command set.The general architecture of this application is presented in Figure 6.The Communication Layer is the one responsible for receiving and transmitting data from and to the HG.The Command Parser recognizes incoming commands and passes them along with their arguments to the Command Processor.The latter, decides what the required action is per command.It could be the transmission of a response, the reconfiguration of some parameters or a control action (start/stop streaming command).If a response is required then the "Response Send" module takes action.It assembles the required response into an application layer packet and delivers it to communication layer for transmission.A response could be a simple acknowledgement or a packet containing information about the current configuration.A different course of action is taken when a control command arrives.In that case, a periodic Timer responsible for triggering the sampling of the sensors is activated or deactivated.When the timer is set and upon expiration, a packet containing the values of the sampled sensors is sent to the Communication Layer.The operation of the application follows from the described architecture.Initially a predefined set of configurations is applied with respect to the type of each mote.By default, every mote is waiting for an incoming command.In TinyOS based platforms the aforementioned architectural components correspond to nesC modules.This is not the case for platforms without RTOS.In those platforms the implementation of the presented architecture is delivered in terms of short independent functions called by the main control loop.On Developing a Novel Versatile Framework for Heterogeneous Home Monitoring WSN networks 9 unique set of commands and command formats independent of the underlying platform.

B. Implementation of the Mote's Communication Module
For every framework aspiring to be flexible and extensible, the support of prominent communication techniques such as 802.15.4 and Bluetooth is fundamental.Thus significant effort was devoted in extending our firmware so as to support 802.15.4 and this section highlights the main implementation challenges tackled.
An important problem we had to solve was related to the manipulation of every mote separately.In Bluetooth this is trivial since a specific port is bound to one and only Bluetooth device and HG uses this port in order to reach it.In the case of 802.15.4,for TinyOS based systems, HG uses a mote with 802.15.4 interface as a proxy in order to reach the rest of the network.This makes broadcasting a command, easier than in the Bluetooth case.In order to use the unicast mechanism provided by the 802.15.4,we had to exploit information contained in the application layer packet reaching our communication module.Specifically, since every mote is assigned a unique id, which is contained in every application packet destined to this mote, the mote acting as 802.15.4 WSN GW resolves the destination address of each packet and integrates this information to the header of each transmitted packet.Of course, this approach requires a basic awareness of the packet format by the 802.15.4 gateway's firmware but reduces the complexity of the application layer design and assures seamless operation between different communication technologies.In the case of Arduino based systems, no processing takes place on the gateway platform.Assuming, the address of every mote is set upon programming, the destination address for every packet leaving the gateway requires a reconfiguration of the GW which is done automatically and on the fly by the implemented module.Another difference between the Bluetooth and the 802.15.4 protocols that we have to harmonize is that the first is byte oriented while the second relies on packet transmission.Since decoupling the application logic from the underlying communication technology was of primary concern for our firmware, a new nesC component was implemented in order to solve the problem in the TinyOS case.This new component exposes the same interface towards the application layer for both communication protocols, while hiding the actual communication implementation.

C. Low level HG -802.15.4 WSN Interface
In our firmware in order to enhance extensibility and versatility of our application, we allow packets of different sizes to be transmitted without considering special manipulation by the application logic or the HG.This is a decision we had to take under account while implementing the low level data exchange interface between the HG and the rest of the network as depicted in Figure 7.In the Bluetooth case, this is straightforward since all is required is reading bytes from a port.Significant effort was required for the low level data exchange between HG and 802.15.4 TinyOS based, gateway.In order to support the common set of commands towards the motes via 802.15.4 a respective Python module was implemented.The python module communicates with the HG through a socket.When activated, the implemented Python module reads data from the socket, coming from the HG and encapsulates them in predefined 802.15.4 packets which sends via serial to 802.15.4 gateway and then to the IEEE 802.15.4 part of the home environment.When a packet arrives, our receive method reads its payload and writes its content to our socket.The HG reads packets from this socket thus closing the communication loop.Finally for the Arduino based platform, a similar approach was adopted.Since communication of a PC to Arduino is based on a serial port, a python module was implemented in this case as well.It reads data from the serial port and sends them through a socket to the HG.An extra feature of this module is that whenever a new packet arrives from the HG, it reconfigures the Arduino based gateway so as to update the destination address in the header of the 802.15.4 packet to be sent.Thus our platform achieved interoperability both with respect to the communication technology as well as the software infrastructure considered.such a system.However, heterogeneous approaches, concerning both software and hardware aspects, must still be addressed so as to offer practically designs and implementations.Therefore, such an effort is presented and discussed throughout this paper analyzing each step starting from requirement identification moving to design choices and finalizing with specific implementation challenges tackled.Through this process a common homogenous practical platform supporting diverse sensors and communication technologies is proposed while offering an efficient and intelligent platform providing the required services.Furthermore, we believe that acquired knowledge and experience made available by this paper can be proven an invaluable tool for future respective efforts.

Figure 3 .
Figure 3. High level TinyOS Software Stack Architecture

Figure 4 .
Figure 4. Middleware high-level architecture Endorsed Transactions on Pervasive Health and Technology 01 -05 2015 | Volume 01 | Issue 1 | e4 On Developing a Novel Versatile Framework for Heterogeneous Home Monitoring WSN networks 7 concepts introduced in the ISO/IEEE 11073-20601 standard.As a first example we refer to the SDP -WSN communication commands.

Figure 6 .
Figure 6.WSN node Functional Block Design Since our main focus was to support seamless interoperation between different communication technologies, platforms and sensors, we decided to use a

Figure 7 .
Figure 7. Home Monitoring System Overview 5 Conclusions Complete and versatile home environment monitoring systems comprise a critical yet daunting objective.The wide ranges of different requirements in several domains as well as the highly sensitive nature of such endeavour pose significant challenges.During the last years significant advancements in wireless sensor networking, highlight respective technologies as adequate basis for On Developing a Novel Versatile Framework for Heterogeneous Home Monitoring WSN networks 3 However, offering respective characteristics comes with the cost of extreme limitations in critical aspects, which comprise Achilles' hill especially regarding processing power, storage capabilities, communication bandwidth and most importantly energy availability.Driven by the aforementioned analysis, the following critical requirements' aspects are identified and taken into consideration as far as development is concerned.

Table 1 :
Packet Structure The SDP can be further extended with new functionalities (e.g.activity recognition, presence, new feedback mechanisms, etc.) and integrate with new services through open APIs and protocols (social networks, hospital, etc.) just by implementing and installing the respective bundles on the OSGI Execution Environment.