Skip to main content

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!

Comments

  1. I'm not sure how much I agree with your contention that TDMA schemes muddy the water between communication substrate and application logic. Nobody's claimed that about token-ring, and IP runs over lots of TDMA links (GSM,LTE,WIMAX, even the GTS parts of 802.15.4). IP doesn't have any particular considerations for this to work… Furthermore, it's simply a fact that TDMA has higher spectral efficiency and can make QoS guarantees. It's not that I'm particularly in favor of TDMA, I'm just agreeing with KJP that it often seems overlooked.

    Of course there are scheduled or pseudo-scheduled MACs around- SCP-MAC or synchronous LPL/B-MAC are pretty well known. I think a better objection is a sort of wariness to baking in a dependence on consistent schedules to your protocol, especially for ad-hoc, multi-hop applications.

    FYI 802.15.4e is on the horizon that has a lot of elements of TSMP-- there's even a (new,open) implementation out of Kris's group-- see http://wsn.eecs.berkeley.edu/projects/openwsn/wiki
    I'm definitely going to be taking a close look at it.

    ReplyDelete
  2. TDMA vs. CSMA? This is what gets sensor nets people excited? My god! The panel sounded like the only useful thing there. Wake up guys. You need to figure out what to use this stuff for! And being limited by quant. analysis is a big problem in other communities also. You need to figure out a way around it. I think the HCI community (my community) is suffering from this same problem, but it is just a "looser" level of rigor. Forcing everything to look like a tight experiment limits what you can ever build and explore. There should be room for both styles of work (tight experiments about something small and looser explorations of big ideas).

    ReplyDelete
  3. Steve - the issue in most WSN scenarios is that we don't have the luxury of completely decoupling the communication and application layers, due to limited buffer capacity and the need to tightly coordinate communication schedules with sampling, computation, etc. The dependence issue is a big part of it; once you have signed up to use TDMA it's hard to back out.

    James - check out the full program; I'm only blogging on a small subset of the papers. It's true that the community is dominated by networking research so the question is, as we start to actually solve those problems, how do we get the community to evolve to work on the next set of hard problems. One problem is that papers that branch out often get out of the comfort zone of the program committee so having the right people on the PC is essential.

    ReplyDelete
  4. James, 802.15.4 actually specifies TDMA and CSMA working together. TDMA is in fact exciting for one major reason and that is power savings. In WSN, that is almost everything. You can duty cycle the whole network so that all devices save power while remaining synchronized to each other's wake up cycle.

    The frequency hopping serves a different purpose which is robustness to channel interference. Believe it or not, the reason why WSNs haven't penetrated more is because people are still tryin to figure out the power issues to keep them on for years at a time without replacing batteries.

    ReplyDelete
  5. Thank you for the information.
    Why this guy Kris Pister don't do that kind fo bussnies with microsft or apple ?
    I think it would be better, well It's just an idea?

    Thanks

    ReplyDelete
  6. What a great company Dust Networks is, my older brother works there and he tells me only wonderful things about the company and how they treat their employees.

    ReplyDelete

Post a Comment

Popular posts from this blog

Why I'm leaving Harvard

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 career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

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 like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…