Advances on the wireless sensor technologies, both in the hardware (memory, processor, sensing device) and software (modularized/loadable operating systems, adaptation middleware, numerous protocol stacks) layers have broadened and triggered many new domains of Wireless Sensor Networks (WSNs) applications: automation system control, smart building, adaptive environment monitoring, to list a few. However, the abundance of WSN applications and the heterogeneity of wireless sensor technologies also raise different challenges: i) a cost-effective middleware solution to share resources of sensor nodes between WSN applications; ii) integration of WSNs middleware services to the enterprise networks, and the Internet, to consider WSN applications as parts of the enterprise systems; iii) common application interfaces for heterogeneous WSNs applications through the standardization; iv) intelligent reasoning for the automatic triggers of adaptation and reconfiguration in WSN applications; and v) reliable and secure control and management of WSNs applications.
Related Projects
Huge research have been carried out in this stage, spanning different areas of WSNs for the adaptation and reconfiguration of WSNs application: network architectures, micro and loadable operating systems (e.g., TinyOS, Contiki), adaptative and lightweight middleware solutions (e.g., FiGaRo, RUNES, WiSeKit), reliable code distribution protocols (e.g., FlexCup, MCP), and so on. At the target sensor nodes, the adaptation and reconfiguration can be in the form of either parameter settings or scripts running over the virtual machines, or the replacement/adding/removing of software components over adaptive middleware and/or loadable operating systems. The related projects with the main concentration in the definition of adaptation and reconfiguration middleware solutions for WSNs include RUNES (Reconfigurable Ubiquitous Networked Embedded Systems), SWISNET (Scalable Wireless Sensor Networks), IBM MoteRunner, and SENSE (Smart Embedded Network of Sensing Entities). Therefore, some of the existing research approaches in WSNs have realized the WSN as a Service to deal with some of above challenges. The new view of WSNs as services (which adopts Web Services (WS), and thus, called Sensor Web) aims at simplifying the publication of and the access to sensor resources. Numerous research projects have been concentrated on different service architectures and standards in the corresponding WSN application domains to support for the Sensor Web. Some (on-going) projects include: i) SANY (Sensors Anywhere), which is based on Open Geospatial Consortium (OGC) Sensor Web Enablement for the development of standards for geospatial and location-based services; ii) NEMBES (Network Embedded Systems), which adopts semantic Sensor Web design (i.e., SensorML developed by OpenGIS, and RDF [Resource Description Framework] developed by W3C Semantic Web technology) to give a Web-based, open distributed system of sensor resources within the building; iii) SOCRADES, which exploits the Service-Oriented Architecture (SOA) paradigm both at the device and at the application levels to develop the WS-enabled sensors and actuators on production lines in the industrial automation systems. Additionally, some sensor companies, e.g., ArchRock or SensiNode, in cooperation with the well-known industrial partners, have released lots of Sensor Web-based applications.
Challenges
However, the realization of WSN as a Service also requires solving the key challenges. These challenges include: i) the management of huge amounts of data continuously produced by sensors, and the reactions to the events inferred from such data; ii) the high resource demands of using Web Services; iii) the underlying binding protocols for using Web Services (e.g., HTTP or SOAP); iv) the network-layer solution for inter-networking WSNs with the external networks (e.g., enterprise networks or the Internet). To address the first challenge, hierarchical network architectures (cluster-based, tree-based, chain-based, or grid-based) are proposed, in conjunction with information reduction techniques (compression, selection, aggregation), and multi-resolution information storage with distributed indexing. The second and third challenges are generally solved through a cross-layer (transport/MAC, and/or transport/network) approach. Finally, current approaches for the last problem are either proxy-gateway based (e.g., via the specific transport protocols for WSNs), or customized versions of TCP (e.g., TCP/uIPv6/6LoWPAN/IEEE802.15.4). In addition to the above on-going projects (SANY, NEMBES, SOCRADES), there are also other works to deal with the above challenges. These work include: i) TinyWeb, which adopts Web services over HTTP/TCP/uIP to enable an evolutionary sensornet system where additional sensor nodes may be added after the initial deployment; ii) TinySOA, which uses a service-oriented approach to make possible to get and send data to a WSN by the means of simple and easy to use web services. However, web services are only provided to Internet users through a server, which communicates with WSNs through a proxy gateway; and iii) TinyREST, which uses HTTP-based REST architecture to obtain or change the state of sensors/actuator. TinyREST also uses a proxy-gateway approach, in which DCP (Device Control Protocol) is used for the network-layer protocol within the WSN.
Progress beyond the state-of-the-art
The SeaS collaboration aims at providing an important progress beyond the state-of-the-art by the means of scientific and technological improvements over existing solutions. These solutions include middleware components and models, which will be integrated within an open-source platform. This platform will serve as a substrate for the development of novel WSN applications strongly connected to the enterprise networks, and the Internet. We therefore intend to reify heterogeneous sensors (virtual/simulated sensors, device sensors, physical sensors) as hybrid services, which can be dynamically managed by the SeaS platform. By adopting the service orientation at the finest level of granularity (i.e., the sensor node instead of the WSN gateway) we will support an end-to-end service-oriented methodology for building the next generation of WSN Internet-based applications). This methodology will offer more flexibility for the management of the collected data while ensuring the ownership of the sensors.
The SeaS proposal does not assume any particular WSN infrastructure and propose to flatten the concepts used in WSN applications in order to simplify the integration of WSN within the enterprise networks, and the Internet. This philosophy is supported by the recent achievements of the IPv6 standards, which promotes the assignment of an IP address to every single object connected to the Internet. Based on these core concepts, SeaS will establish the foundations for a set of key reusable services for WSN applications. These services will address two dimensions: the sensor and the network. All these services will be packaged as components in order to encourage their reuse. The sensor services will be deployed directly on the sensor nodes in order to provide the basic support for the WSN applications. These services will cover business concerns (i.e., data collection) and non-functional concerns (e.g., activity management, communication protocols, reconfiguration support). The network services will be deployed on top of the sensor services and will provide advanced features for the WSN applications. These advanced features include the definition of virtual dedicated gateways, and the real-time processing of collected data. Virtual gateways will exploit the Cloud computing paradigm to offer a virtual infrastructure to WSN application developers. This infrastructure will manage the provisioning of resources (i.e., the sensors) by the means of service level agreements. The real-time processing of collected data will enforce the delivery of collected data by monitoring the status of the infrastructure and the quality of the collected data in order to satisfy the time and memory constraints requested by the WSN applications. Finally, we also intend to provide a facility for ensuring the continuity between WSNs and ubiquitous devices by enabling mobile devices to access the processed information or be notified of related events triggered in the physical world.