Design and implementation of a framework for efficient and programmable sensor networks

Abstract

-Wireless ad hoc sensor networks have emerged as one of the key growth areas for wireless networking and computing technologies. So far these networks/systems have been designed with static and custom architectures for specific tasks, thus providing inflexible operation and interaction capabilities. Our vision is to create sensor networks that are open to multiple transient users with dynamic needs. Working towards this vision, we propose a framework to define and support lightweight and mobile control scripts that allow the computation, communication, and sensing resources at the sensor nodes to be efficiently harnessed in an application-specific fashion. The replication/migration of such scripts in several sensor nodes allows the dynamic deployment of distributed algorithms into the network. Our framework, SensorWare, defines, creates, dynamically deploys, and supports such scripts. Our implementation of SensorWare occupies less than 180Kbytes of code memory and thus easily fits into several sensor node platforms. Extensive delay measurements on our iPAQ-based prototype sensor node platform reveal the small overhead of SensorWare to the algorithms (less than 0.3msec in most high-level operations). In return the programmer of the sensor network receives compactness of code, abstraction services for all of the node's modules, and in-built multi-user support.

Enhanced Coordination in Sensor Networks through Flexible Service Provisioning

“…Some scripting systems, including Maté [34], ASVM [35], SwissQM [40], and Agilla [19], enable reprogramming. Other systems, including Melete [51] and SensorWare [11], enable multiple applications to share a WSN. All of these systems come with different scripting languages [33,23,37,50].…”

Node-Level Energy Management for Sensor Networks in the Presence of Multiple Applications

“…a piece of code that executes in one node, henceforth named task) wishes to be transferred and executed in a specific node, it needs to carry some attributes with it. The attributes along with the current node state N N (e.g., remaining energy, parameters of tasks already running in the node) will determine the task's admission (or not) based on some policy P. The energy management system proposed here, fits in a greater framework for programmable WASNs described in [4]. The interested reader can find information on distributed application creation and deployment in [4].…”

“…The attributes along with the current node state N N (e.g., remaining energy, parameters of tasks already running in the node) will determine the task's admission (or not) based on some policy P. The energy management system proposed here, fits in a greater framework for programmable WASNs described in [4]. The interested reader can find information on distributed application creation and deployment in [4]. In our energy management system there are three types of attributes: Energy attributes {e attr }, reward attributes {r attr }, and policing attributes {p attr }.…”

“…Viewing the energy consumption at higher-levels is beneficial for our purposes. Usually, applications built for WASNs use services and protocols already provided by sensor nodes [4][6] [9]. Describing the energy consumption in low level attributes, such as transmitted bits, reception time, and computation time, would be impossible since the application does not have any knowledge of sensor node resident services and protocols.…”

“…This vision is currently supported by a series of frameworks that try to make WASNs dynamically programmable and generally open to transient users [4][6] [9]. "Multiple different requests for physical information, arriving at different times", translates into "multiple different applications running concurrently in the network while multiple requests for execution of new applications are constantly received".…”