Saturday, November 14, 2009

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.

12 comments:

  1. I think the quote is something like "In science, people stand on the shoulders of giants. In computer science, we stand on each other's toes". And it certainly wasn't David Culler who said it first.

    ReplyDelete
  2. Of course Culler was not the first - but he is known to say this. I'll clarify.

    ReplyDelete
  3. Interesting post!

    The community seems to generally consider the MAC layer an area that does not need to be further investigated. But if this would have been the case, we would expect to have a large number of different, functional MAC layers around. We would also expect that everyone would always use power-saving MAC layers in all their experiments. The MAC layer makes all the difference in terms of power consumption: run your system with no power-saving MAC layer, and it dies in a few days. Use a power-saving MAC layer, and it can live for years.

    If MAC layers were a "finished" area, we'd expect to have extensive support for various MAC layers in our operating systems. But TinyOS only supports LPL and defaults to running with no MAC layer. And Contiki provides only two: LPL (X-MAC) and optionally LPP (low-power probing).

    To a large extent, a great deal of papers completely disregard the MAC layer. The authors run experiments using an always-on radio protocol, thus depleting their battery in days. Such systems would never work in any kind of real reployment, yet TPCs continue to let those papers through. Maybe this is because the MAC layer has become such a dreaded area that authors feel that if they mention the MAC layer, their paper will be immediately rejected?

    Perhaps it is time for the community to rethink our standpoint on MAC protocols?

    ReplyDelete
  4. jkp - I will come right out and say that MAC protocol design, while somewhat interesting, is clearly not what is going to carry the sensor networks community for the next decade. If our focus remains only on low-level services we are going to miss a huge opportunity to have an impact on the rest of the world and the future of the Internet. I argue that there are MAC protocols that are "good enough" to take us to the next level; just like TCP/IP was "good enough" to support the tremendous impact of the Internet. Arguably the Web - which started as a dumbed-down ASCII protocol - is what made the Internet happen, not some arcane tweak to TCP congestion control. Personally I think it's time to get our heads out of the sand and look beyond the little camps we've formed in the sensor network community, and start talking about where the next big opportunities lie. MAC protocols ain't it.

    ReplyDelete
  5. Matt: great point regarding MAC protocols and low-level services. But there is a risk in us repeatedly saying that one particular area is complete, when there are still things to be done in that area. I dare to say that MAC protocols are one of the strongest contributions that the sensor networking community has done: they allow us to treat the sensor network as a network, while still maintaining a low power consumption. Some of the early work on sensor networks investigated other ways to view the sensor network, where nodes were sleeping and unavailable. With a MAC protocol, we do not need to handle that complexity any more - we just run our sensors as a network.

    I agree that low-level mechanisms aren't the bright and glorious future for sensor networks. Low-level mechanisms seldom are. Yet, much of the strength of the sensor network field comes from these numerous low-level aspects: things like stable operating systems and MAC layers to available hardware designs is what has made this community so strong.

    Compare this to the ubicomp camp, which traditionally has put more value in a cool demo than on low-level technology. Thus the community has showcased many cool demos, but has produced very little of usable technology.

    I agree that the sensor networking community should turn our eyes away from our belly buttons and towards the skies. But we shouldn't forget that the low-level details still are important when building torwards the next-generation opportunities.

    ReplyDelete
  6. jkp - I never said that MAC protocols were "done", just "well-trodden", which is not the same thing. If I were talking to a new faculty member about what research direction to head in, I think recommending that they work on MAC protocols would be very risky. It's unlikely that you can publish such work in a major conference (unless you make a pretty major breakthrough, though I'm not sure there are major breakthroughs yet to be made in that area), and given the large amount of mediocre research on MAC protocols it is hard to stand out. It is a very crowded space.

    I do agree that SenSys has taken a strong systems stance that is valuable and should not be abandoned. As we start branching out it is important to maintain the high degree of rigor that we have established in that community.

    ReplyDelete
  7. Matt: I wasn't specifically referring to you when I reacted to the "MACs are done" idea - I was thinking more about the community in general, where a lot of people seem to have this idea. But I completely agree with you that I would not recommend any one to go all-in on MAC layer research. With a duty cycle of < 1% (by many MAC protocols), it is hard to improve state of the art in the area. Yet, people should not forget their tremendous importance.

    I believe the sweet spot for SenSys would be in the combination of the systems and low-level aspects that it currently has, with the interesting applications emerging from the union of traditional ubicomp systems, the "Internet of Things" (sensors and actuators moving into everyday objects and scenarios), "cyber physical systems", and real-world aspects promoted by the IPSO Alliance and their likes. There are a great deal of interesting problems hiding in there.

    Your list of open problems is very good. I would also add integration and interaction with existing large-scale systems to the list. When large-scale data input from large numbers of devices meets large-scale data management, there are interesting questions to be asked: for example, where and by whom should data filtering be performed (if at all)? Questions like those cannot be completely answered by looking only at the sensor network, but must involve the outside world as well.

    ReplyDelete
  8. This comment has been removed by the author.

    ReplyDelete
  9. In my view the field has a very good projection for the next ten to, os, sensor networks can be a very good alternative to give better service to students, students must take this opportunity.

    ReplyDelete
  10. If MAC layers were a "finished" area, we'd expect to have extensive support for various MAC layers in our operating systems.

    ReplyDelete
  11. Hello.. Firstly I would like to send greetings to all readers. After this, I recognize the content so interesting about this article. For me personally I liked all the information. I would like to know of cases like this more often. In my personal experience I might mention a book called Green Parks Costa Rica in this book that I mentioned have very interesting topics, and also you have much to do with the main theme of this article.

    ReplyDelete