Justin Manweiler, Ph.D. Candidate in Computer Science at Duke University, and adviser Dr. Romit Roy Choudhury may soon be my heroes. They figured out how to slow battery depletion to a trickle when using Wi-Fi. Peers also tout the duo, giving the researchers an award at MobiSys 2011, which is no small feat.
In their paper, “Avoiding the Rush Hours: WiFi Energy Management via Traffic Isolation,” the research team explains why conserving battery power is difficult:
“Our key ﬁnding is that WiFi energy optimizations have conventionally been designed with a single AP in mind. However, network contention among different APs can dramatically increase a client’s energy consumption.
Each client may have to keep awake for long durations before its own AP gets a chance to send packets to it. As the AP density increases in the vicinity, the waiting time inﬂates, resulting in a proportional decrease in battery life.”
Wi-Fi radios have always been a drain on batteries, but it’s worse now. Today, the Wi-Fi landscape is a battle zone. Wi-Fi-equipped phones and notebooks have to deal with multiple APs and possibly hundreds of other clients in a contentious battle for the right to transmit.
Then there is streaming media and social network apps that are constantly updating. What’s a poor battery to do?
Fortunately, you can rest more with SleepWell. It is formulated to help APs and clients avoid the mess. And, unlike partisan antics, clients and APs cooperate, thank you very much.
I had thought that the 802.11 protocols had some of this built in already. I must be wrong, or today’s environment must be congested enough to overwhelm existing technology.
Either way, I wanted to find out about SleepWell. I’m tired of lugging those extra batteries. So, I contacted Justin Manweiler, asking a bunch of questions, such as:
Kassner: I thought techniques such as Power-Saving Mode (PSM) were implemented to help prevent your key finding from happening. I now assume that’s incorrect. Would you explain why?
Manweiler: PSM is thoughtfully designed to save energy for Wi-Fi clients when they have no traffic to send or receive. The clients “sleep” during these periods of inactivity.
Our finding is somewhat different. It considers those periods when the client would like to be awake. That is, it has some outstanding traffic to send or receive. What we find is that the other wireless background traffic going on in the network can make these operations more energy-inefficient.
Kassner: I read in the paper that SleepWell improves upon what exists today by paying attention to the following:
- Distributedly scheduling trafﬁc bursts to achieve quick convergence
- Ensuring clients do not get disassociated during dynamic rescheduling
- Preserving channel utilization, latency, and fairness, even under trafﬁc variation and node churn
Would you explain how each helps?
Manweiler: The bullets are technical features of the design and prototype we created. Let me take a step back. The key idea in the system is to isolate client traffic. That is, clients should choose to use the network when other clients aren’t.
How we achieve this is by smarter scheduling of client access to the network. It is “distributed” in the sense that there is no central piece of infrastructure creating this schedule. Instead, all devices cooperate to reach a more efficient usage of the network.
The schedule is flexible, so it is important that clients do not get “disassociated” from their network access point. Clients must receive continuous, uninterrupted service, even as the schedules change.
Finally, the last point simply says that our system does not have significant overheads or performance drawbacks, even in complex usage situations.
Kassner: Now, we know the problem. Let’s take a look at your solution: SleepWell. What is it? Hardware? Firmware? How does it work?
Manweiler: SleepWell is a software-only solution that runs on network access points or wireless routers. No changes (even in software) are made to mobile phones or laptops. The access points and wireless routers running the SleepWell system make small changes to optimize their operations, yielding dramatic energy savings for their clients.
Kassner: The following slide shows how SleepWell affects the client:
Please explain what we are looking at.
Manweiler: This is a graph of raw-power consumption on two Nexus One phones. The top graph shows one. The middle graph depicts the other. These two graphs were measured at the exact same time. Note that when one phone is using the network, the other is not. The third graph shows a Nexus One phone without SleepWell. Power consumption is continuously high for the same workload.
Kassner: Did I read that correctly? Energy reductions varied from 38 percent to 51 percent. That is significant.
Manweiler: This shows how much energy a fixed workload (TCP file transfer, YouTube, or Pandora) requires with a high level of background traffic — from nearby access points and clients. SleepWell reduced the energy consumption under heavy background traffic to more closely match the energy consumption when there are no other devices nearby.
Kassner: According to the 802.11 protocol, if transmission characteristics are less than stellar, the AP will reduce the bit-rate (bandwidth) so as not to lose any traffic from the client. That tactic will cause the total energy cost of transmitting the same quantity of traffic to skyrocket, simply because it takes longer to transmit.
The energy-usage spike does not occur when SleepWell is controlling the network. That has to save a bunch of electrons. The above graph maps the test results. How is that possible?
Manweiler: The reason has to do with how the Wi-Fi network is being used. In a wireless network, channel time is a finite resource. When bit-rates are low and correspondingly, transmission times are long, each AP will place a greater stress on the network capacity as it attempts to use more channel time.
In these cases, the efficiency improvements provided by SleepWell become important, the greater the network utilization, the more background traffic that SleepWell will sleep through – relative to regular Wi-Fi.
Note that in the graph, SleepWell’s energy requirement is fairly steady, irrespective of transmission bit-rate. The effects of background traffic are much larger than that of bit-rate on any individual link.
Kassner: I know I am going to get asked this. Does all this sleeping affect throughput?
From the slide, it appears that it doesn’t. How can that be?
Manweiler: SleepWell just adjusts traffic patterns. It finds a more efficient schedule, does so without significant overheads, and the aggregate network capacity remains the same.
Kassner: Last question. Well, last three. What’s next for SleepWell? Can existing equipment be retrofitted with SleepWell? When could we expect it?
Manweiler: I would certainly like to see SleepWell adopted, and soon. Since it is a software-only solution, it should be possible to retrofit existing equipment. If not, I believe Wi-Fi-hardware vendors could integrate it into the next generation of Wi-Fi access points and routers.
Telecom providers are begging users to move to Wi-Fi to free up bandwidth on their backhaul systems. Users would be more than happy to — for the increased bandwidth — if that didn’t cause their batteries to bleed profusely. SleepWell could be the proverbial saving grace for both.
Thank you, Justin, because your research has given me hope. And a special thanks for allowing me to use quotes and graphics from your paper.