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.
I've posted a story to Medium on what it's been like to work at a startup, after years at Google. Check it out here.
The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in ...
My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go . I say "almost" because ...
I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds l...