The Future of Sensor Networks

I am occasionally asked by new faculty and grad students (at other schools) whether they should get involved with sensor networks. The concern is that the field has "peaked" and there are risks associated with jumping into an area that may have past its prime. I'm not sure I agree with this assessment. It is true that much of the low-hanging fruit has been picked: after all, the field has been active for about a decade. Rather, I see this as an opportunity to ask where should the field be going in the next ten years. We had a panel on this topic at SenSys 2009, for example. A few thoughts.

First, I think it's important for anyone (new faculty member or grad student) to avoid being too narrow in their research scope. I have always considered myself a "distributed systems person" with a recent fetish for sensor networks, not a "sensor networks person" per se. The set of questions I am interested in find manifestations in sensor networks, but also in clusters, mobile systems, Internet-scale systems, and other domains. That said, it never hurts to ride a wave of burgeoning interest in a research area, as a way of establishing yourself in a community and having impact. To that end the question is whether sensor networking currently offers the right mix of hard problems and trendiness to build a career.

The popularity issue is hard to gauge, but I am convinced that there are some very hard problems in this space that few groups have yet looked at. Most folks probably agree that MAC protocols, routing, localization, and other foundational system services are well trodden problems by now. I'll throw out a few problems that I consider wide open, and by no means is this an exhaustive list.

Managing networks of billions of sensors: Let's say that sensor nets do become massively widespread (some would argue this is well underway). I'm not sure we know how to effectively manage or evolve billions of wireless sensors distributed throughout our environment. Anyone who has deployed a non-trivial sensor network has had to undertake a great deal of manual effort to program the nodes, track their health and behavior over time, and keep tabs on simply where they are. In most computer systems, the ratio of humans to computers is fairly high, so it is reasonable to expect some level of manual effort. Currently, we largely treat sensor nets the same way, but this simply does not scale. We need much better tools and mechanisms for deploying and managing vast networks. Further, as new sensor nodes are introduced into an environment, with new capabilities and software, how do we integrate them with older sensors and allow the entire ecosystem to evolve?

Coupling sensor networks with actuation: This is a hot topic right now and generally falls under the rubric of "cyber-physical systems." I believe we have a very poor understanding of how to synthesize data from a large number of embedded sensors that may be poorly calibrated, not functioning properly (or at all), and exhibit high degrees of spatial diversity. Adding on actuation -- either control of an external system, or direct actuation by the sensor/actuator nodes themselves -- opens up a whole slew of hard problems. We'll need to reason about stability, robustness, and latency. Existing approaches to distributed control will need to take the nodes' resource limitations and failures into account.

Programming and reasoning about complex network-wide behavior: Finally, I am still convinced that our approach to programming large networks is fairly ad hoc. How many times have you read a paper about a protocol or distributed algorithm that involves a tremendous amount of complexity, and for which it's unclear how it will operate in different settings or in conjunction with other code? There are many smart people (I am not one of them) who know how to design complex distributed algorithms, but the devil is in the implementation details, and it's easy to get those wrong. Reasoning about the dynamics of a large sensor network subject to variable loads and resource conditions is extremely difficult, and currently we resort to tuning our code by hand. It's possible that a combination of language, compiler, and runtime support could help automate much of this painstaking design process, but this will require good models and analytical techniques to understand network dynamics at scale.

I think there is plenty of fruit still on the tree, but we need to climb higher up to see it. An "entry level" project for someone wanting to get involved in sensor nets should probably not be to design a new MAC layer or try to solve the localization problem. It's great that systems like TinyOS have matured to the point that lowers the barriers to entry for new researchers; as David Culler likes to say, the hope is that a new researcher in the field can stand on the shoulders of giants, rather than on their toes.

SenSys 2009, Day Three

Today's the last day of SenSys 2009. Some pictures from the poster and demo session are up on the CITRIS website.

The morning session on time synchronization features one of the award papers -- Low-power clock synchronization using electromagnetic energy radiating from AC power lines. This is a very well-executed paper that leverages specialized hardware to pick up the magnetic field radiating from AC power lines to establish a common 60 Hz clock source for a set of sensor nodes. Nodes measure a common frequency but experience local phase offsets, which are corrected for using message exchanges. The hardware only consumes 58uW so this is a very practical approach. If this hardware were widely available, this could be the last word on time synchronization, at least in settings where nodes are deployed in the vicinity of (not necessarily plugged into!) AC power - including buried and overhead power lines.

Shuo Guo from University of Minnesota gave a talk on FIND: Faulty Node Detection for Wireless Sensor Networks. The idea is to look at differences in the ranking between nodes' sensor data and the estimated physical distance from a target to detect sensor faults. This assumes that there is a monotonic relationship between distance to a target and a node's sensor reading. The paper seems to consider a fairly narrow definition of a "fault" and I'm not sure how well this maps onto the kinds of faults seen in real world deployments, nor how this would relate to Byzantine faults caused by buggy or malicious code.

Jung Il Choi from Stanford gave a talk about a network protocol isolation layer, to enable multiple protocols (e.g., CTP and Drip) to coexist without stomping on each other. The isolation layer allows multiple protocols to share a radio link fairly, and observe the same LDR when other protocols are active. This is accomplished using a grant-to-send mechanism that bounds the times when protocols can transmit (to avoid self-interference) and fair queueing. This strikes me as being quite similar to Balakrishnan's Congestion Manager, though without explicit feedback to applications.

Overall the conference was great this year, and the venue worked very well to keep the audience engaged. At the same time it is a huge relief to have it all wrapped up. Looking forward to SenSys 2010 in Zurich!

SenSys 2009, Day Two

Report from Day Two here at SenSys.

Last night at the organizing committee dinner I had the pleasure of chatting with Kris Pister, founder of Dust Networks and the originator of the term "smart dust". I got to pick his brains on the state of sensor networks in industry and the gap between academic work in the area and real-world demands. Kris had a couple of interesting comments. Dust Networks has made major inroads into wireless sensing for industrial automation and is behind the Wireless HART standard. He noted that academics are generally allergic to leveraging fine-grained time sync to enable TDMA and coordinated channel hopping, which can greatly improve reliability. It's true that most academic work favors a CSMA approach. I think there are two reasons for this: first, we don't happen to have a good TDMA implementation for, say, TinyOS that is easy to integrate with existing code. Second, once you go down the TDMA route it taints many aspects of your system design as it tends to violate layering between application logic and the communication substrate.

Kris also noted that a lot of the academic work in this area (including papers in this years' conference) are reporting results that are worse (or at least no better) than what the industrial solutions manage today. I can't prove or disprove this claim but it is true that the academic community is largely unaware of what the industry state-of-the-art is capable of. Kris has been trying to publish papers on their Wireless HART protocol but these kinds of papers are generally not well received by program committees. I do think it would help to have a strong evaluation-driven paper published about this protocol.

A few highlights from today's talks.

Kevin Klues from Berkeley gave a talk on TOSThreads, a threading mechanism for TinyOS. One of the main complaints about programming in TinyOS is that the event-driven programming model requires fairly straightforward programs to be broken up across a set of event handlers. Threading support would make it easier to write simple applications, although it's not clear how much benefit this will have for more complex applications with a high degree of concurrency. Mostly I'm concerned about how one reasons about interactions between threads and the ability to couple activities across them to increase energy efficiency. TOSThreads is a somewhat minimal approach to introducing threads into TinyOS, making it easy to couple threaded and event-driven code, but introduces the distinction between low-priority application threads and a high-priority "kernel" (not a distinction that we have seen in TinyOS before). I think the jury is out on whether this is the right direction but it can make writing simple programs much easier.

My former Ph.D. student, Konrad Lorincz, gave a talk on our Mercury system, which manages energy and radio bandwidth for a network of wearable sensors being used in neuromotor disease rehabilitation studies. Naturally this was the best talk of the conference.

Nithya Ramanathan from UCLA gave a talk on Suelo, which is a system for monitoring contaminants in soil and groundwater. The key challenge is detecting and dealing with faults in the sensors, especially as they are deployed for long periods of time in challenging environments. Suelo adopts a hybrid of autonomous and participatory sensing, by automatically dispatching people to check or replace sensors when data outliers are detected. The system also incorporates feedback from humans to tune the fault detection algorithm. This is a curious paper - it is not a conventional "technology centric" solution. The paper is backed up by data from three deployments (Bangladesh, San Joaquin River, and James Reserve). This is a very important problem for real, long-term sensor network deployments and needs techniques that sometimes are outside of the conventional CS literature. I'm glad this paper is at SenSys.

Rajesh Gupta moderated a panel on "Sensor Networks - The Next Ten Years", looking at the future directions for the field now that we are about a decade in. Mani Srivastava argued that we've moved away from sensing as a key aspect of WSNs, and even further from the potential to do actuation. He admonished the community to focus more on mobile personal sensing. Of course, this involves human factors, such as incentives, user interface design, and privacy. Jack Stankovic thinks the focus will morph into "cyber-physical systems", involving greater interaction with the physical world. To make this work, he argued that we need guaranteed real-time wireless communication as well as formal validation for safety. Joe Paradiso talked about sensor nets as an extension to the nervous system and asked how people will interface with them. His claim is that ubiquitous computing will arise from existing, commodity devices originally intended for other purposes. Finally, Pedro José Marrón talked about the European Cooperating Objects initiative which brings together pervasive computing, sensor nets, and embedded systems.

One thread across these position statements is that the set of open problems is very diverse - and often the solutions are not easily quantified. Perhaps one reason these problems have been less the focus of SenSys is that it is hard to get a quantitative handle on them: it's more difficult to publish papers when you can't show graphs that go up and to the right. By the same token it's hard to get a grad student to go work on a problem dealing with, say, human factors -- at least in the systems and networking community. Joe pointed out that this is more common in other communities, although the methodology (e.g., user studies) can be fairly limiting as well. As a community I think we tend to gravitate towards problems that leverage the techniques and methodologies we feel comfortable with, which in turn constrains the set of problems we tackle.

The poster and demo session followed the presentations. The demos are a real highlight of SenSys and give researchers a way to showcase real systems.

At the banquet we announced the two best paper awards. They are VTrack: Accurate, Energy-Aware Traffic Delay Estimation Using Mobile Phones from MIT and UIC, and Low-power clock synchronization using electromagnetic energy radiating from AC power lines from CMU. Congratulations to both sets of authors!

SenSys 2009, Day One

I'm here in Berkeley for SenSys 2009, the premier venue on sensor network systems. There are 21 papers in the conference this year (out of about 120 submissions) and the quality of the papers is very high. The proceedings have been posted online here. I happen to be the program co-chair along with Jie Liu from MSR, so I feel compelled to blog about the conference.

This morning, Bill Weihl from Google gave the keynote presentation on "The Power of Energy Information." He talked about Google's PowerMeter system which allows consumers to track and visualize the power consumption in their homes -- potentially allowing people to learn about their patterns of electricity use and identify anomalies (like a broken air conditioner). Bill also talked about preliminary work at Google to shift power generation load through smart charging of plug-in electric vehicles, dynamically turning charging on and off across fleets of vehicles based on the grid's fluctuating capacity. It was a great talk and emphasized the potential for large-scale information on energy consumption.

A few highlights from some of my favorite talks today.

Om Gnawali from Stanford gave a talk on the Collection Tree Protocol, which is now the default routing protocol in TinyOS. CTP is the result of a substantial effort to increase robustness and reduce route maintenance overheads for large-scale spanning tree networks. Perhaps the best part of the paper is that they ran extensive measurements on about a dozen sensor network testbeds (including our own MoteLab testbed) to validate the protocol's performance. It is interesting to see the variation in performance across different settings.

Mike Liang from JHU gave a talk on RACNet, a sensor network designed to collect temperature and other data in large datacenters. Unlike "conventional" sensor networks, RACNet uses powered nodes (plugged into the USB port on a server rack) so the need to use, say, low-power MAC protocols is not a concern. RACNet focuses on a token-based data collection protocol to achieve high reliability across a range of node deployment densities, for networks with hundreds of nodes. This is an unusual setting for wireless sensor networks since one might imagine that it is trivial to have the servers themselves collect this data, but it's actually better to have a separate monitoring network that does not directly impact the servers.

Arvind Thiagarajan from MIT gave a talk on VTrack, which uses sparse localization data from mobile phones -- using a combination of GPS and WiFi localization -- to estimate travel time delays for individual road segments. This system provides high-resolution estimates of drive times through "crowdsourcing" mobile phone location data. This involves correcting noisy location estimates using an HMM to map trajectories to road segments. They evaluate the system on more than 800 hours of drive data from a fleet of taxicabs in Boston. I'm glad this paper made it into SenSys since it is not a paper about motes and TinyOS, and points the way towards future directions for the field.