Skip to main content

WhiteFi: Wi-fi like networking in the UHF White Spaces

This week our paper, joint with Microsoft Research, on White Space Networking with Wi-Fi Like Connectivity was presented at SIGCOMM 2009, where it actually won the best paper award. This paper lays the foundations for the first Wi-Fi like network operating in the UHF white spaces (that is, the portions of the TV spectrum unoccupied by TV channels, wireless mics, and other devices). There's been some press on this work from Technology Review, Engadget, and other sites. My student, Rohan Murty, gave the talk. He is pictured to the right, apparently wearing the UHF antenna on his head -- I am not sure whether this improves his mental capacity or not. (Update 8/24/09: The slides are now available.)

By way of background, in 2008 the FCC issued a ruling allowing unlicensed devices to operate in the UHF white spaces, under certain restrictions. Opening up this spectrum for unlicensed wireless networks is a huge opportunity -- for example, UHF devices would achieve much longer range than networks operating in the 2.4 GHz and 5 GHz ISM bands. There's been a lot of recent research on establishing individual links in the UHF white spaces, but to our knowledge nobody has proposed a network design allowing multiple clients to communicate via an access point. That's where WhiteFi comes in.

Networking in the UHF white spaces raises a number of interesting challenges. The first is that the spectrum is fairly fragmented, and we can make use of variable-width channels (unlike the standard 5 MHz channels used by existing 802.11 networks). This makes AP discovery more difficult since there are many combinations of center frequencies and channel widths that would require scanning.

The second is that, by FCC mandate, a white space device must avoid interfering with any "primary users" of the spectrum. TV channels are relatively easy to avoid, given that they don't tend to come and go (although a mobile device would need to determine when it is coming in range of a new station). It turns out that wireless microphones also operate in this band, and of course you can't predict when one might be turned on. This requires the use of channel sensing to rapidly determine the presence of a wireless mic and mechanisms for switching an access point and any associated clients over to a new channel when interference is detected.

In WhiteFi, the key idea is to use a software-defined radio to scan the physical RF channel and use an efficient algorithm for performing AP discovery without performing a full decode on the signal. The SIFT technique (described in the paper) is a simple time-series analysis of the raw samples from the SDR that quickly determines if there is an AP operating at the chosen center frequency, as well as its probable channel width. The SDR is also used to detect incumbents. WhiteFi also includes algorithms for assigning channels to APs based on spectrum availability, as well as for handling disconnections due to interference or station mobility.

Going forward, we are continuing to collaborate with Microsoft Research and are developing a white space testbed here at Harvard that will allow us to experiment with these ideas at larger scales. Ranveer Chandra, Thomas Moscibroda, and Victor Bahl from the Microsoft Networking Research group are all involved in this effort.

Comments

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…