Design Principles of Audio-Visual Content- Capable ... - CiteSeerX

Design Principles of Audio-Visual ContentCapable Wireless Sensor Networks André Rodrigues, Jorge Sá Silva, Fernando Boavida CISUC, Department of Informatics Engineering, University of Coimbra, Portugal {arod, sasilva, boavida}@dei.uc.pt

Abstract—The diverse application domain of Wireless Sensor Networks (e.g., habitat, ambient, home and factory monitoring) has impact on multiple parameters (e.g., deployment strategy, node mobility, available resources, topology, sensor coverage, Quality of Service, network size, lifetime, and connectivity). There is also diversity on the node hardware, from small capability nodes like MicaZ or TMote to more powerful ones like iMote2 or SunSpot. This hardware heterogeneity can enable applications to make a better use of the resources, with the more powerful nodes processing AV streams / aggregating the information and the others collecting simpler variables. On the other side, all this diversity is an obstacle to the development of a standard platform (hardware / software) that eases the task of building sensor networks applications. In this document, we present the design principles of an adaptive middleware solution that can be applied to home and environment monitoring scenarios supporting node mobility, AV content, actuator capabilities and Internet access. We also describe the testbed that is being developed at the University of Coimbra in order to evaluate the performance of middleware solutions for the above scenarios.

I. INTRODUCTION Programming wireless sensor nodes using only the usual operating systems (e.g. TinyOS, Contiki, SOS, and Mantis) takes time and need some expertise on embedded systems. So how can we reduce the learning curve? The usual answer is middleware that abstracts the details and offers to the developer a higher layer interface, sometimes enabling the query of the network as whole. Other recent trend, is based on the idea of direct access to the node supported on IP (6LowPAN - Contiki) enabling the use of IP tools and Web technologies. Others (e.g. ArckRock) added to this approach the capability to access sensor data thought Web Services (via gateway node). More powerful hardware nodes like iMote2 or SunSpot ease the development making use of Linux or Java based environments and tools. These types of nodes are interesting, but some applications do not require all this capabilities and cannot justify the extra cost. The purposed idea is based on the fact that if the developer had a programming environment where he could specify the application functionality, the requirements and have access to an automatic tool to generate and deploy the code on the sensor nodes (the middleware solution selecting the best components that fulfill the application requirements at compile time and after the deployment phase, monitor the performance and adjust configuration parameters) it would be useful.

This kind of adaptive idea is not novel but there are only a few working implementations [4] and we also want to add extra functionality, namely support for AV content, Web services support and support for highly constrained hardware. The testbed that is being developed at University of Coimbra (UC) will enable us to test the performance of this middleware in two scenarios. The first one being an intelligent home support system to increase the quality of life of elderly people, by offering new services and increasing the bounds between family members; and the other a remote environment monitoring solution located at the Berlenga island. There are a few Wireless Sensor Network (WSN) middleware classifications already available, in order to better evaluate our work, one of them will be summarized in Section 2. Section 3 presents the state of work at our laboratory. Conclusions and topics for further work are described in the last section. II. MIDDLEWARE CLASSIFICATION There are few classifications of WSN middleware [1, 2, 3, 4]. In [1], middleware solutions are grouped as: Classic – solutions that offer abstractions for communication primitives, paradigms and application requirements but are somewhat limited in QoS, mobility and adaptability requirements (e.g. Impala); Data centric – the network is abstracted as a database with queries based on some form of SQL-based language enhanced to support energy efficiency and WSN specific requirements. Adaptability, reconfiguration and QoS are not well supported (e.g. TinyDB); Virtual machines – each node offers the services of a virtual machine that executes a high-level language. This approach is flexible, energy-efficient at the communication level and supports security at code level. However, it presents overhead in processor time and higher energy consumption due to the virtual machine execution (e.g. Maté); Adaptable – the idea is to support adaptability (in the same way as described in the introduction). Flexibility, cross-layer optimization and QoS support are advantages, but the complexity may not be acceptable for some environments. The authors presented their solution TinyCubus, another middleware that also focus on heterogeneity and resource scarcity is the RUNES. .

III. KEY DESIGN PRINCIPLES It’s our point of view that in a near future several WSN development environments will coexist, each one targeting a few groups of applications. More specifically, we are not targeting the application space of large scale adhoc sensor networks. As already stated, we intend to test our middleware in small scenarios. In order to justify some of the middleware requirements we will present a subset of the functionalities to deploy in the indoor scenario: - video support to enable vigilance, communication between the family members or friends, access to the caregivers, and to diagnose abnormal activity (changes in the routine of the elderly) - environment parameters monitoring (e.g. temperature and humidity) could be used to configure the environment and to alert in critical conditions (e.g. high temperatures). The capability to alert on gas, flooding, fire or intrusion is also very interesting - vital parameters’ monitoring like Heart Beat or activity recognition are useful features. Sleep pattern analysis and fall detection are other examples. There are other possible services, like reminders for meals and for medication, but this set already enables us to present some requirements the middleware must support: - mobility (e.g. persons move around) - real-time (e.g. alert generation and AV content) - fine grained node synchronization (e.g. to enable activity recognition based on data from multiple nodes on the body) - security on the data and fault tolerance on the applications. Other requirements derive from the need to reduce application development difficulty and from the necessity to integrate diversity at the hardware and communication levels. All of these requirements support the architectural decision that the system will comprise two main tiers Application Tier and Sensor Network Tier. At the Application Tier the WSN functionality is exported as Web Services in a Service Oriented approach and the applications make use of a discovery mechanism to know the available services. These services are component based, executing in an application server that interfaces to the sensor network(s), and implement functionalities like parameter visualization, registration

and alert. One important aspect is the fact that the system abstracts diverse real networks: one main sensor network based on 802.15.4 nodes, another 802.11 network to support the video cameras (that are also represented as sensor and actuator nodes because they support movement detection and can directly interface to sensor and actuators devices) and, for example, an X10 network (in this technology it is possible to have devices that only transmit or receive information). The application developer can create new components to support additional services. At the Sensor Network Tier (e.g. a TinyOS based 802.15.4 WSN) the Application Tier services could map to a set of components being executed at the network nodes. At each node a component execution framework enables the execution of the components (e.g. localization, security, synchronization, routeing) that are selected at design phase (according to the application requirements) and may change some components in runtime to react to changes in the environment / nodes. Mandatory components include the ones needed to directly access the node from an IP network. The tesbed being developed at UC includes MicaZ nodes with diverse sensor boards (including GPS support and Cyclops cameras), Stargate gateways with USB cameras and Axis 207W network video cameras. Some nodes are mobile based on robots and small cars. Network access technologies used at coordinator PC include 802.3, 802.11, Bluetooth, GSM and UMTS. The system can be accessed from any PC, PDA or mobile phone. IV. CONCLUSIONS AND FUTURE WORK This paper presented the characteristics that we considered in the development of our WSN middleware solution, some application requirements and the testbed being developed. The next steps will be the extensive testing and refinement of the middleware solution. REFERENCES [1]

[2]

[3]

[4]

P. J. Marrón, “Middleware approaches for sensor networks,” Summer School on WSN and Smart Objects (Schloss Dagstuhl, Germany, Aug 29 – Sept 3, 2005). K. Terfloth and J. Schiller, “Driving forces behind middleware concepts for wireless sensor networks,” In Proceedings of the REALWSN Workshop (Stockholm, Sweden, June 2005). K. Römer, “Programming paradigms and middleware for sensor networks,” GI/ITG Fachgespraech Sensornetze (Karlsruhe, Karlsruhe, Feb 26-27, 2004). K. Henricksen and R. Robinson, “A survey of middleware for sensor networks: state-of-the-art and future directions,” In Proceedings of the international Workshop on Middleware for Sensor Networks (Melbourne, Australia, November 28 – 28, 2006).