[maemo-users] Power consumption and WLAN APs

From: Kalle Valo kalle.valo at nokia.com
Date: Mon Jul 21 12:39:53 EEST 2008
"ext Frederic Crozat" <fred at crozat.net> writes:

>> What power-management issues have you seen affecting battery life ?
> I think it is usually caused by interoperability deficiency between
> 770/n8x0 and some routers wifi chipset regarding PSM (Power Saving
> Management) part of wifi specification.

Exactly. The problems stems from the fact PSM was (and still is?)
mostly unused by the windows laptops. So it seems that some AP
manufactures decided to omit the testing of the PSM implementation

Why is PSM so fragile then? Since I can't sleep (jet lag, argh), I'll
write a bit about this.

PSM problems can be categorised into two classes, packet loss and
increased power consumption. But first few definitions:

PSM = Power Save Mode
CAM = Continous Aware Mode, ie. PSM turned off
AP = Access Point
client = a PC or N8x0 connecting to AP
downstream = from AP to client
upstream = from client to AP
frame = packet with WLAN headers sent to the air

If we omit few details, PSM is actually quite simple. Every WLAN frame
has a PSM bit in frame control structure and this bit tells the frame
receiver (AP) the status of transmitter (client). If the bit is set,
the client will go to sleep mode. And naturally if the bit is not set,
the client will stay awake (is in CAM mode). When AP knows that the
client is sleeping it must not send the frames, but buffer them for
later use.

But even though the client is sleeping, it still wakes up for the
beacons transmitted by the AP. The beacon interval is very accurately
defined in the spec, we are talking about microsecond precision here.
So the client can wake up just before the beacon and go back to sleep
right after it has received the beacon. This is how the huge power
consumption saving is possible.

If the AP has buffered frames for the client, it will set the so
called TIM bit for the particular client in the beacon. When a
sleeping client receives the beacon, it will check the TIM bit. If the
bit it is set, the client now knows that AP has buffered frames and
requests the frames from the AP. If there are more buffered frames, AP
will set the MoreData bit in the frame control to notify client. Then
the last buffered frame is being transmitted, AP will clear the
MoreData bit. That way client will know that there aren't anymore
buffered frames. Also after AP has transmitted all frames succesfully
to the client, it will unset the client's TIM bit in beacons.

If AP has buffered broadcast or multicast frames, it will mark a
special broadcast/multicast TIM bit in beacons. This bit tells the
clients that there will be broadcast/multicast frames after this
beacon. When the bit is set, client will not go to sleep immeaditely
after the beacon, but only after it has received all the
broadcast/multicast frames. If there are only few frames, they should
be sent in few milliseconds and the power consumption shouldn't
increase that much.

Ok, that's a short summary how PSM works. I hope it makes it easier to
understand what I'm writing next. As I said, this was very high level
overview of the Power Save Mode. For exact specifications I recommend
to read IEEE 802.11-2007 standard, which is freely available from the
IEEE site.

Now back to the what I really wanted to write about:

Packet loss with PSM happens usually in downstream direction. This is
because most of the time client is sleeping and if the AP transmits
the frames directly without buffering, the client can't receive them.
There is a small window during waking up for beacons when the client
might be able to receive even unbuffered frames and that's why some of
the frames might go through. In this case the packet loss might be
around 90%.

Other way to break PSM is to not set the TIM bit at all, so the client
would have no way to notice that AP has buffered frames. Or, like in
one case, the AP did set the broadcast/multicast TIM bit, but it just
set the bit on the beacon which was sent after multicast traffic. One
would need a time machine to catch that :)

And about the increased power consumption, that's usually related to
incorrect user of either TIM or MoreData bits. I have seen cases where
the TIM bit in beacons is not cleared even though there are no
buffered frames. So the client will request frames after every beacon,
but there won't be any. Also I have seen a similar problem with the
MoreData bit not cleared by the AP.

> I'm seeing this kind of issue between my work AP (Linksys) which have
> working PSM and my home AP (Freebox, a set-top-box provided by my
> ISP), where PSM is not working properly with a maximum uptime of 8h
> when wifi is on.

It sounds like PSM is not working at all with your home AP.

> I've been in contact with one of my ISP engineers who is taking care
> of writing wifi driver in their set-top-box. From the first
> investigation, it seems Conexant chip (used on Nokia tablets) was
> known to be problematic (Freebox is using Ralink chipset).

I doubt that the Conexant chipset itself is the problematic one, most
probably all chipsets using PSM (with PS-Poll frames) would be
problematic. We have tried to solve a lot of the PSM problems with
Conexant, and usually the problems have been in AP. And usually even
in the i-need-a-time-machine category just to be not able to
workaround them.

I'm quite confident that the PSM mode in the Conexant chip is working
fine. Of course there might be bugs lurking somewhere, I don't deny
that. But I want to see concrete proof of that before I'll believe it :)

> A first bug was found in ralink proprietary driver which was losing
> AP association after some time in PSM mode, which was fixed by
> Ralink.

Hmm, I would first suspect that the AP is not really buffering all
frames. I have seen APs which periodically send Null frames to check
that the client is really alive. Maybe the AP vendor forgot to check
if the client is sleeping when they send the Null frame? Wouldn't be
the first.

> Unfortunately, this fix was not sufficient to fix the power
> consumption issue and we are kind of stuck now :(

Too bad :(

> If Eero or another Nokia hackers have some information which might
> help Freebox engineers to track the issue, I'll be happy to serve as a
> proxy.

Dealing with vendors is very slow, it takes hours and hours of work,
consisting mostly writing emails. I simply don't have time for that,
and I rather write code than email. 

But what I could do is to analyse the problem myself. It would take
only an hour or two, including writing a small report about the
problem which I can send everyone interested (hopefully this includes
the vendor). So if you would be able to convince the vendor to send
the AP for a loan? If that's not possible, are you coming to Maemo
Summit? If I manage to come and you can take the AP with you, I could
take a look at it onsite.

Please note that I might not be able to join the Summit because of a
reason or another. So don't travel long journeys just because of this
testing session.

This offer is available for others coming to the Summit as well. If
you have badly behaving APs (with PSM or some other problems), take it
with you and I'll take a look.

BTW, is there a bug about this? If not, please file one. I'll forward
it to our IOP testers so that they could try get access to the AP as

>> Would it affect other laptops as well or just the tablets ?
> I guess it will depend on laptop wifi chipset. And compared to Nokia
> tablets, entire laptop power consumption is way more important than a
> tablet, so if wifi is too important, it is probably hidden by other
> component consumption.

I'm guessing that none of Windows drivers use PSM. I have seen in few
drivers PSM setting hidden somewhere very deep in the driver settings
maze, but it has been always disabled by default. But I don't use
Windows, so someone more knowledgable can give you an better answer.

Kalle Valo

More information about the maemo-users mailing list