Check out the new USENIX Web site.

Home About USENIX Events Membership Publications Students
EESR '05 Paper    [EESR '05 Technical Program]

A File System Abstraction for Sense and Respond Systems

Sameer Tilak1, Bhanu Pisupati2, Kenneth Chiu1, Geoffrey Brown2, Nael Abu-Ghazaleh1
1Computer Science Department, State University of New York (SUNY) at Binghamton
2Computer Science Department, Indiana University

Abstract

The heterogeneity and resource constraints of sense-and-respond systems significantly challenge system and application development. In this paper, we present a flexible, intuitive file system abstraction for organizing and managing sense-and-respond systems based on the Plan 9 design principles. A key feature is the support of multiple views of the system via filesystem namespaces. Constructed logical views present an application-specific representation of the network, thus enabling high-level programming. Concurrently, structural views of the network enable resource-efficient planning and execution of tasks. We present and motivate the design using several examples, outline research challenges and our plan to address them, and describe the current implementation state.

1  Introduction

The heterogeneity and resource constraints of typical sense-and-respond (S&R) systems pose daunting challenges to system and application development. These challenges are further exacerbated by the lack of simple abstractions for the use and development of these systems. In this paper, we show how the principles of Plan 9 [1] can be applied to S&R systems, resulting in flexible, intuitive systems supporting multiple logical views. Applications can then use the view with the most appropriate organization and abstraction.
Sense-and-respond systems typically comprise a diverse set of hardware and software elements. Hardware elements include a wide variety of different sensor and actuator types, ranging from COTS to highly-specialized, one-of-a-kind parts. Software elements draw from numerous domains, including the natural sciences, artificial intelligence, sensor networks, and embedded systems. Further increasing the diversity is the various ways in which the software and hardware elements may interact, such as event-driven, polled data, or data streams. This heterogeneity greatly complicates the development of reliable, effective S&R systems.
Figure 1: An example wireless sensor network in a zoo. Sensors track animal locations and resources such as food and water. The network is divided into two clusters, each consisting of a cluster head.
A crucial component of many S&R systems is wireless sensor and actuator networks. These networks promise to revolutionize sensing in a wide range of civil, scientific, military, and industrial applications. For example, numerous sensors may be deployed around a city to monitor chemical and biological threats, or in the wild to monitor ecological events in migration patterns [2], or to track a smoldering forest fire for conditions that might lead to an outbreak. Responses may range from alerts to the use of actuators to mitigate the damage.
The inherent resource constraints of WSNs pose significant challenges to this vision. Wireless sensors are limited in power, weight, and size; also, communication is often unreliable. These constraints exacerbate the problems created by the heterogeneity of S&R systems.
Successfully addressing these multi-dimensional challenges relies crucially on developing an effective abstraction for sensor networks. A simple and well understood abstraction can significantly ease both system and application development. Many sensor networks are deployed by scientists and researchers whose expertise is not computer science. Providing these scientists with a simple and intuitive interface to program, access, configure, and debug sensors can facilitate deployment of large scale sensor networks to a great extent.
Motivated by this need, we propose a simple yet powerful filesystem-based abstraction of sensor networks based on Plan 9, which espouses that the file system metaphor (as seen, for example, in the /proc file system) can be adopted for almost all aspects of system design and development. Not only can files be used to store a named sequence of bytes, but also to replace many aspects of communication and control that are typically performed using system calls. A key feature of our proposed solution is the ability of the application to define multiple namespaces to organize the sensor network in an application specific manner. Another advantage is that we can now exploit, perhaps with some adaptation, much of the work in distributed file systems, such as Coda [3] to address various systems issues such as consistency models.
Another commonly proposed abstraction of WSNs is that of a database [4]. Typically, these databases present application-level information, isolated from the resources providing the data. Upstream data acquistion and processing then lacks resource knowledge, precluding the application of the end-to-end principle and complicating efficient implementations. Infrastructure services also cannot be built on the database abstraction, since by nature these require low-level resource information. In contrast, by providing logical and structural namespaces, our file system abstraction can present information at a wide variety of levels, making it suitable both for building applications and infrastructure.
We model a sensor network as a set of clusters, each with a cluster head. Cluster membership is normally determined geographically. Our model is intended merely to provide a concrete basis for demonstrating the utility of our file system abstraction, and not as an end in itself. With this abstraction, an application might access sensor data geographically by reading from a path /location/54W/35N/data, or logically such as /data/temperature/snakes.
This paper contributes a file system abstraction for sensor networks and a proof-of-concept implementation within the ns-2 simulator. The Plan 9 protocol for implementing the file system abstraction, Styx, has already been well-researched on various distributed computing platforms. We thus focus our attention on its implementation in sensor networks.

2  Proposed Filesystem Abstraction

The application of file system abstractions to sensor networks is inspired by the tenets of the Plan 9 and Inferno operating systems [1][5], whose defining feature is the uniform treatment of devices and files. This section describes the use of the file system abstraction as a convenient and efficient means to view, access and program sensor networks.
Figure 1 shows a sample network deployed in a zoo, with sensors tracking animals and resources such as food and water. The network is divided into two clusters each consisting of a cluster head. The sensors themselves may each differ in functionality (temperature/position), hardware type (MSP/AVR), and software platform. Figure 2 shows a typical directory layout for such a network.
Figure 2: Namespace for a sensor network.
The file system representation naturally captures the structure of the network in addition to depicting logical attributes such as aggregation properties and groupings. The root directory network encapsulates the whole network. It has a subdirectory for each cluster, each which in turn has three subdirectories named sensors, aggrData, and groups. The sensors directory provides direct access to the sensors and has one directory corresponding to each. A lot of sensor network applications are data centric and often however, rather than the individual sensor values, what is of interest is the aggregate value of a property observed at different sensors. These cluster-wide properties can be readily retrieved via the aggrData directory, which contains files avgTemp and avgLight, representing the average temperator and average light readings, respectively. We thus embed "intelligence" into the file system, enabling it to process and interpret data (such as averaging individual readings), rather than just storing and presenting it. Finally, the groups directories demonstrate the logical grouping of the sensors according to specific criteria. The grouping shown is based on animal type, but could have been based on geographic location of the sensors.
The task of locating and denoting a sensor device effectively reduces to finding the path for its corresponding file in the namespace. Sensor 1's value, for instance, is read from /network/cluster1/sensors/s1/reading. The low level operations inherent in retrieving the values are cleanly abstracted by the file interface, which also conceals heterogeneity among sensors.
Another example of using this interface is that of configuration and debugging of sensors. The file system can translate writes to the control file to control operations on the sensor, such as reset, wakeup, or sleep. The file system may also facilitate debugging by exposing the sensors' registers and memory as files. An external debugger can then use the file system interface to debug software executing on the sensors. described in the next section.
The file system approach can flexibly partition functionality at different levels of the network, such as at the sensor, cluster head, or client; thus providing a single paradigm even for end sensor devices that may be computationally lightweight. Logically combining multiple networks now becomes analogous to mounting the networks' file system representations under a common directory.

3  Architecture

As in Plan 9 and Inferno [1][5], all resources are named and accessed as files within a hierarchical directory structure, implemented using the Styx protocol from Inferno[6]. Systems can overlay arbitrarily complex data and sensor policies using multiple simultaneous namespaces, each providing a different perspective of the same physical sensor network.
A client that wishes to interact with a sensor network mounts the associated file system from a server and executes the appropriate file operations. The client and server interact using the Styx messaging protocol to encode the various file operations. Message are always exchanged in pairs, with the client initiating the exchange and the server responding. The client starts a session by connecting to a server using a Tattach message. The client may then navigate the directory tree using the Twalk message (analogous to the UNIX cd command). Other standard operations such as opening, reading, and writing to files are performed using the Topen, Tread, and Twrite messages respectively. These operations may block, but multiple outstanding requests may be issued to compensate.
Client applications do not directly issue Styx messages, but rather use a software library we provide. The interface consists of typical file operations such as open, read, and write. Details of the underlying messaging protocol are completely concealed from the client application.
The file server implementation of sensor networks has two components in its core, namely device-level file servers and multiplexers. Device-level servers reside in the leaf sensors, and define a static directory structure and methods for accessing individual files (really named resources). These fundamental servers provide the most basic interactions with the sensors such as reading the value and primitive control operations. Correspondingly, these servers store minimal dynamic state about themselves and and active clients, and hence require limited runtime memory.
Multiplexers merge different device-level file systems, and would typically reside in the cluster heads to provide a cluster-level namespace. At startup time, the multiplexer engages a discovery process to determine the topology of its associated sensors. It then reads the static directory structure from the device level file systems of all sensors to create cluster-level file system hierarchy. When a client requests a file operation, the multiplexer uses the file descriptor in the request to map (multiplex) and reissue the request to a particular device file system in its namespace. Multiplexers can receive and process new requests while waiting for a reply from an outstanding request to a device file server. A multiplexer also has other responsibilities including collection of data from multiple sensors and applying aggregation functions (such as average) to it. It manages logical groups of sensors shown in the groups directory in Figure 2. Sensors are sorted into groups during startup and also afterwards when new sensors come online.
Multiplexers offer great flexibility in partitioning application, configuration, and debugging functionality between different components of the sensor network. Consider a debugger application that is debugging code executing on a sensor node. The debugger typically requires access to registers and memory on the sensor. Instead of implementing the low-level functionality to retrieve these values in the debugger itself, the functionality can instead be implemented in the device-level servers as files, with the multiplexer in the cluster head providing higher-level organization. The debugger then accesses the registers and memory indirectly by reading and writing to these files, upon which the device-level server performs the necessary low level procedures. As another example, migration from a simulated sensor network to a real network is straightforward. The device file servers can present the same file interface to the application regardless of whether the server is accessing a simulated sensor or a real sensor.

4  Research Challenges

We have identified following research challenges specific to using the file system abstraction in a sensor network environment.
Supporting resource efficient operation: Abstraction such as those mentioned in Section II hide complexities of the underlying system, and provide rich and intuitive interfaces to the end user. Since wireless sensors are often resource-constrained, however, the implementation of the file system abstraction must be reasonably efficient; and thus the protocols must be designed to operate within severe constraints on computational power, energy, and storage. We selected the Styx protocol in part because it is lightweight, and does not impose excessive overhead, as detailed in Section VII.
Application-level operations must also be resource-efficient, and so we propose the construction of a standard resource namespace that exposes resource information to the application, such as the available energy or storage space on a given sensor node. The following challenges are identified.
Supporting resource efficient operation: Abstraction such as those mentioned in Section II hide complexities of the underlying system, and provide rich and intuitive interfaces to the end user. Since wireless sensors are often resource-constrained, however, the implementation of the file system abstraction must be reasonably efficient; and thus the protocols must be designed to operate within severe constraints on computational power, energy, and storage. We selected the Styx protocol in part because it is lightweight, and does not impose excessive overhead, as detailed in Section VII.
Application-level operations must also be resource-efficient, and so we propose the construction of a standard resource namespace that exposes resource information to the application, such as the available energy or storage space on a given sensor node. Section VI describes an example of resource-efficient query execution.
While the filesystem abstraction provides mechanisms for creating and maintaining namespaces, it does not define how they should be organized (separation of policy from mechanism).
Consistency models: By nature, WSNs are dynamic, concurrent systems. Thus, clients' view of the namespace and even data may be inconsistent with respect to the current actual state. For example, a client may use the namespace to determine that a particular mobile sensor is in a specific region, but discover when it actually reads data from the sensor, that it has moved out of the previously determined region. Or, stale, cached sensor readings may be sent to a client as a result of transmission interruptions.
Strong consistency models could be implemented using distributed locks and other techniques, but the nature of WSN applications generally suits weak consistency models. Sensor data is by nature unreliable, and applications usually do not rely on high-quality, consistent operation. Adopting the file system abstraction, also allows us to apply existing research in distributed file system consistency models [3] to sensor network domain.
Managing streaming data: Sensors typically produce stream data representing their samples over time. Stream data is not directly supported in the Styx framework; extensions to the file system abstraction to model streaming devices may be required. We are currently working on extending Styx protocol so that streaming data can be handled more efficiently.
Supporting in-network application-specific processing: Our framework supports in-network aggregation in the following two ways. In the first approach, a user can extend the existing Styx server to incorporate the required functionality. The Styx server implementation is fairly simple and easy to extend. In the second approach, the user implements the functionality within an independent dynamic library. The Styx server then loads the dynamic library at run time as needed, and unloads them when unneeded to free up memory.
For applications with relatively static requirements, such as a debugging application which needs access to sensor registers and memory, the first design choice is a better option. Also, very commonly used aggregation functions including average, min, max can be implemented within the Styx server. However, for applications that require more sophisticated in-network processing or whose functionality changes more often, the second design choice is a better option.
Tolerating network unreliability: Wireless channels are susceptible to fading and interference. Furthermore, to conserve energy, sensors often turn off their radios for extended periods of time. This intermittent connectivity poses unique challenges to filesystem design. One partial solution is to cache relatively static sensor information in the cluster head, which can then respond to queries even when communication to the sensor is interrupted.

5  Additional Capabilities

Using a file system abstraction offers additional advantages for application developers in a sensor network. Some of these are reviewed in this section.
Ease of application development: The file system interface is well understood (both semantically and syntactically) by application developers and system programmers. This interface can be easily used by scientists and researchers who are not familiar with the intricacies and low-level details of sensor network systems.
Access control via file permissions: File systems incorporate simple but flexible access control mechanisms via file permissions. For example, the permissions on a sensor control file might grant write access to the administrator group to allow calibration, while only granting read access to normal users to allow querying the current device state.
Ease of integration: We believe that tools designed in other contexts can be easily made available to use in sensor network environments. This includes, for example, development and visualization tools developed for desktops, PDAs, or even distributed systems. These tools can then be ported to the proposed file system abstraction with an effort significantly lower than having to develop them from scratch.
Portability across sensor architectures and protocols: The file system abstraction using the Styx protocol can serve as a bridging layer for interoperating heterogeneous sensors as well as interactions with external devices. In this sense, it plays a role similar to that played by IP in interconnecting heterogeneous networks. Once a new device has support for file system/Styx primitives, it is able to interoperate with the remainder of the system.

6  Examples

In this section we demonstrate the capabilities of the file system abstraction with three examples.

6.1  Sensor Monitoring and Calibration

Monitoring the resource state of sensors is an important capability for sensor networks [7]. Moreover, sensor calibration is essential for reducing the noise in the sensor data [8]. The file system provides mechanisms to discover sensors, as well as read and write their state, which allow the application developers to rapidly and even interactively monitor and calibrate the sensor network. For example, the following commands can be issued by a client to discover the temperature sensors in an area, read the remaining energy of one of the sensors, and then write a parameter to calibrate another.
mount /dev/network /network
ls /network/cluster1/sensors/
cat /network/cluster1/s1/remaining-energy
echo 2.5 > /network/cluster1/s1/control

Note that an application-specific namespace can provide S&R functionality similarly to the example above. We may monitor for sensors reading a temperature higher than a threshold, look for actuators near them, and then control the actuators, for example, to initiate a cooling response in those areas.

6.2  Data-Centric Application

The second example illustrates how the filesystem abstraction supports a data-centric operation representative of a S&R system. Effective S&R operation requires in-network processing to localize interactions and reduce the size of the data transmitted by the sensors [9]. For example, data from multiple sensors can be aggregated to reduce the overall data size transported to an observer. Or, the data may be analyzed to detect events and initiate responses close to the event location, reducing the cost of data transmission and enhancing response time.
Consider an example where the average temperature in a region (region 10) is periodically reported to a monitoring stationg. We describe the planning and execution of this task from a centralized server perspective for simplicity; however, the namespaces may be maintained, and the task planning carried out, hierarchically and in a distributed fashion
First, the application namespaces are consulted to discover the sensors in that region by using ls /network/location/region-10/*. This determines that cluster 1 is within the area of interest. The location information in the namespace is now used to find a set of sensors with the appropriate coverage. In addition, we may consult an energy-based namespace where sensors are categorized in terms of their remaining energy. This allows the application to avoid selecting sensors with low available energy (e.g., S4 and S5) leaving only high remaining energy sensors who satisfy the coverage requirements (S1, S3, S6, S7).
Resource namespaces can also support detailed query planning by tracking network-level resources-in our case to determine the routing and aggregating nodes in the network. These namespaces may include sensor connectivity, bandwidth availability, and resource availability. At the end of this step, the task planning is accomplished, and a suitable set of sensors, the dataflow in the network, and in-network processing is determined.
The query is executed as follows. The source sensors are tasked with an appropriate reporting rate (which can later be adapted) to their upstream neighbors as per the determined dataflow path. Basic sensors have support for sending and receiving packets, but some sensors (e.g., cluster heads) support Styx servers and act as multiplexers. Communication between the sensors forming the dataflow is set up using Styx. Application specific in-network processing can be accomplished by customizing packet handlers in these multiplexer nodes. This can be done dynamically (allowing specialized handlers to be moved to appropriate places in the network), statically (at compile time, or within the Styx protocol), or by allowing the application to select among a menu of predetermined handlers.

6.3  Heterogenous Response System Architecture

Figure 3: An S&R system.
In the first example, we demonstrated how we can control actuators embedded with the sensor network to generate the required response. In this example, we describe the flexibility of the proposed framework in terms of incorporating a wide range of heterogenous devices. As an example, consider a S&R system (Figure 3) deployed in a chemical factory to detect any gas leakage. The response generation system takes input from a range of chemical sensors, processes it and then generates the necessary response. The response might include local activities such as controlling actuators embedded within the sensor network or it might include contacting external entities and authorities or both.
If the system is built using the file system abstraction, it might have a directory called /mnt/Emergency and the response generation system might organize different responses under this directory. For example, upon detecting gas leakage, it might set an alarm to alert local workers and activate the actuators on a sprinkler in order to turn it off. In addition, it might SMS events to medical professionals and e-mail other local authorities.
In many cases, the task force is formed in an ad hoc fashion without any knowledge about underlying sensing infrastructure [10]. With the proposed framework a new device can be mounted on the fly under the /mnt/Emergency directory and the concerned authority can start getting the notification messages immediately. Also, inter-organization communication can be accomplished more easily using simple file commands.

7  Implementation

We have implemented a prototype which integrates the Styx protocol library with the ns-2 simulator [11]. In the current implementation, during the initialization phase, the cluster head (CH) discovers the neighboring sensors and since the CH is running the Styx file server, it simulates sensing devices as files in a file system hierarchy. In the current implementation, we have incorporated the support for constructing various namespaces within the Styx server. Then the client starts the session with the CH by calling the attach function exposed by the client-side Styx library. The client-side Styx library then encodes this command into a low-level Styx message which is sent over the wireless channel. The Styx server running on the CH interprets this incoming Styx message, processes it, and sends a pointer to its root directory to the client, again using the Styx protocol. It should be noted that, the client-side Styx library exposes a clean file system interface and hides all the low-level details of the Styx protocol from the client. Upon getting the pointer to the root directory, the client is able to navigate this directory structure using the walk command and it reads the files using the read command. In essence, the simulation set-up supports the capability required by the sensor network monitoring example described in Section VI. In addition, with our simulated prototype, we are able to simulate a sensor network consisting of at least few hundred sensors.
We have also developed the basic infrastructure for implementing the file system abstraction on real sensors such as the Stargate and Berkeley motes. We have developed a lightweight file server model suitable for the Motes, which consists of about 1000 lines of code and is less than 8KB in size. Our design incorporates the fact that these Motes have reasonable about of flash memory (a few KB) but much less RAM (few hundred bytes), by extensive use of static structures such as device tables and by judicious use of dynamic memory. We have also adopted the less demanding event-driven model as opposed to using runtime threads. Once this implementation is complete we hope to start using it in problems concerning resource monitoring, calibration, and distributed debugging all leading to more complex data centric applications.

8  Conclusion

Sense-and-respond systems are typically heterogeneous and resource-constrained. Under these conditions, system and application development is difficult, especially for domain experts and other developers whose specialty may not be embedded systems. In this paper we have demonstrated how a simple and well-known abstraction, that of a file system, hides much of the underlying complexity, allowing developers to focus on the fundamental challenges of S&R systems. Our initial results with a prototype on the ns-2 simulator suggest that such an abstraction can be practically implemented. Our next step is to port our implementation to a physical WSN such as one constructed from Stargate and Motes.

References

[1]
R. Pike, D. Presotto, S. Dorward, B. Flandrena, K. Thompson, H. Trickey, and P. Winterbottom, "Plan 9 from Bell Labs," Computing Systems, vol. 8, no. 3, pp. 221-254, Summer 1995.
[2]
P. Juang, H. Oki, Y. Wang, M. Martonosi, L. S. Peh, and D. Rubenstein, "Energy-efficient computing for wildlife tracking: design tradeoffs and early experiences with zebranet," in In Prof. of ASPLOS 2002.
[3]
J. J. Kistler and M. Satyanarayanan, "Disconnected operation in the coda file system," ACM Trans. Comput. Syst., 1992.
[4]
Y. Yao and J. Gehrke, "The cougar approach to in-network query processing in sensor networks," SIGMOD Record, 2002.
[5]
S. M. Dorward, R. Pike, D. L. Presotto, D. M. Ritchie, H. W. Trickey, and P. Winterbottom, "The inferno operating system," Bell Labs Technical Journal, Winter 1997.
[6]
R. Pike and D. M. Ritchie, "The styx architecture for distributed systems," Bell Labs Technical Journal, 1999.
[7]
Y. Zhao, R. Govindan, and D. Estrin, "Residual energy scans for monitoring wireless sensor networks," in IEEE Wireless Communications and Networking Conference (WCNC'02).
[8]
K. Whitehouse and D. Culler, "Calibration as parameter estimation in sensor networks," in Workshop on Wireless Sensor Networks and Applications (WSNA) 02, 2002.
[9]
D. Estrin, R. Govindan, J. Heidemann, and S. Kumar, "Next century challenges: Scalable coordination in sensor networks," in Proc. 5th ACM International Conference on Mobile Computing and Networking (Mobicom), 1999.
[10]
K. M. Chandy, B. E. Aydemir, E. M. Karpilovsky, and D. M. Zimmerman, "Event webs for crisis management," in Presented at the 2nd IASTED International Conference on Communications, Internet and Information Technology, 2003.
[11]
"Network Simulator," https://isi.edu/nsnam/ns.



File translated from TEX by TTH, version 3.67.
On 16 May 2005, 11:14.

This paper was originally published in the Proceedings of the Workshop on End-to-End, Sense-and-Respond Systems, Applications, and Services,
June 5, 2005
Seattle, WA

Last changed: 1 June 2005 aw
EESR '05 Home
USENIX home