[ath9k] mesh powersave hardware sleep + wakeup

[ath9k] mesh powersave hardware sleep + wakeup

[Marco Porsch]

Hi,

I am trying to implement the IEEE 802.11s power save schemes in mac80211.
In 11s it is defined that power save STA doze AND send beacons AND wake 
up periodically for multiple neighbors beacons.

Is this actually possible with current hardware/drivers (especially ath9k)?

Regards
Marco Porsch



PS: More details:

We currently have power mode indication and state
tracking and are working on powersave frame buffering and mesh
synchronization.

A next topic will be to put the hardware to sleep to actually save energy.
Until now we only implemented in mac82011. I looked through mac80211 and
ath9k and am unsure, how to actually manage sleep and wakeup in the mesh
context.
Maybe I should give a brief introduction to IEEE 802.11s powersave here:
- Each node has to send its own beacon
- Power mode is not global, but link-specific
- 3 power modes: active, light sleep, deep sleep
   - active = always on
   - light sleep = wake up for the neighbors beacon
   - deep sleep = only wake up for sending own beacon

So the critical point here is, that we need to put the hardware to sleep 
but wake up for:
- sending own beacon
- TBTT of all neighbors towards we are in light sleep (or maybe all 
neighbors as proof-of-concept)
so it is a mixture of ad-hoc , station code and completely new stuff.

A better explanation and a nice example of IEEE 802.11s powersave is 
given here:
http://dl.dropbox.com/u/31741282/11s_powersave.pdf

Re: [ath9k] mesh powersave hardware sleep + wakeup

[Luis R. Rodriguez]

On Fri, Mar 16, 2012 at 10:42:02AM +0100, Marco Porsch wrote:
> Hi,
> 
> I am trying to implement the IEEE 802.11s power save schemes in mac80211.
> In 11s it is defined that power save STA doze AND send beacons AND
> wake up periodically for multiple neighbors beacons.
> 
> Is this actually possible with current hardware/drivers (especially ath9k)?
> 
> Regards
> Marco Porsch
> 
> 
> 
> PS: More details:
> 
> We currently have power mode indication and state
> tracking and are working on powersave frame buffering and mesh
> synchronization.
> 
> A next topic will be to put the hardware to sleep to actually save energy.
> Until now we only implemented in mac82011. I looked through mac80211 and
> ath9k and am unsure, how to actually manage sleep and wakeup in the mesh
> context.
> Maybe I should give a brief introduction to IEEE 802.11s powersave here:
> - Each node has to send its own beacon
> - Power mode is not global, but link-specific
> - 3 power modes: active, light sleep, deep sleep
>   - active = always on
>   - light sleep = wake up for the neighbors beacon
>   - deep sleep = only wake up for sending own beacon
> 
> So the critical point here is, that we need to put the hardware to
> sleep but wake up for:
> - sending own beacon
> - TBTT of all neighbors towards we are in light sleep (or maybe all
> neighbors as proof-of-concept)
> so it is a mixture of ad-hoc , station code and completely new stuff.
> 
> A better explanation and a nice example of IEEE 802.11s powersave is
> given here:
> http://dl.dropbox.com/u/31741282/11s_powersave.pdf

I don't have time to review this but it sounds correct that the part
you want to focus on is introducing a wake up mechanism when you
need to initiate radiation for your own beacons. I think right now
we simply disable PS in mac80211 completely if we have a mode of
operation that require beconing. Your challenge is to lift that and
deal with the issues there and all the possible combinations. You
can help with this

This should help you:

http://wireless.kernel.org/en/users/Documentation/Power-consumption

For now you can focus on only allowing through Mesh devices and
the combinations of it but I suspect that some of the work you do
may also help with addressing P2P powersave.

  Luis

Re: [ath9k] mesh powersave hardware sleep + wakeup

[Marco Porsch]

On 03/16/12 21:45, Luis R. Rodriguez wrote:
> On Fri, Mar 16, 2012 at 10:42:02AM +0100, Marco Porsch wrote:
>> Hi,
>>
>> I am trying to implement the IEEE 802.11s power save schemes in mac80211.
>> In 11s it is defined that power save STA doze AND send beacons AND
>> wake up periodically for multiple neighbors beacons.
>>
>> Is this actually possible with current hardware/drivers (especially ath9k)?

[ ... ]

> I don't have time to review this but it sounds correct that the part
> you want to focus on is introducing a wake up mechanism when you
> need to initiate radiation for your own beacons.  I think right now
> we simply disable PS in mac80211 completely if we have a mode of
> operation that require beconing.

Actually the whole power save code is only written specifically for 
managed mode.
E.g. for ad-hoc, you wouldn't suspend the radio, since the MAC schemes 
that must deal with the resulting deafness issues are not implemented in 
mac80211. (That would be frame buffering + release in ATIM window, ...)

Concerning mesh, I already have a hackish - but mostly working - PS 
frame buffering and release.
But, what is power save without actually saving power?

Problem: I don't have a reference how to suspend/wake the radio between 
sending beacons.
That's why I hoped you can tell me, if - at least in theory - the 
hardware/ath9k even allows this.

 > Your challenge is to lift that and
> deal with the issues there and all the possible combinations. You
> can help with this
>
> This should help you:
>
> http://wireless.kernel.org/en/users/Documentation/Power-consumption

Thanks, the numbers are nice I can use them for analytical estimation or 
simulation.

> For now you can focus on only allowing through Mesh devices and
> the combinations of it but I suspect that some of the work you do
> may also help with addressing P2P powersave.

Correct. When this is implemented, it is easy to port this to ad-hoc. 
Because mesh is definitively more complex, but similar.

Regards,
Marco

Re: [Greenmesh] [ath9k] mesh powersave hardware sleep + wakeup

[Marco Porsch]

On 03/16/12 23:09, Marco Porsch wrote:
> On 03/16/12 21:45, Luis R. Rodriguez wrote:
>> On Fri, Mar 16, 2012 at 10:42:02AM +0100, Marco Porsch wrote:
>>> Hi,
>>>
>>> I am trying to implement the IEEE 802.11s power save schemes in mac80211.
>>> In 11s it is defined that power save STA doze AND send beacons AND
>>> wake up periodically for multiple neighbors beacons.
>>>
>>> Is this actually possible with current hardware/drivers (especially ath9k)?
>
> [ ... ]
>
>> I don't have time to review this but it sounds correct that the part
>> you want to focus on is introducing a wake up mechanism when you
>> need to initiate radiation for your own beacons.  I think right now
>> we simply disable PS in mac80211 completely if we have a mode of
>> operation that require beconing.

I did some hacking and can now answer part one of my question:
yes, beaconing and power save are not mutually exclusive with ath9k [1].

Second question: what about power save doze and waking up for _multiple_ 
neighbors' beacons?

Currently the whole sleep scheduling seems to be determined by 
conf->beacon_interval and conf->dtim_period in case of a station 
(client). Unfortunetely, these are the same variables that determine the 
STAs own beacon interval in case of AP/mesh/ad-hoc. Additionally, for 
mesh mode we will need a whole list of wake-up events (light sleep 
neighbors' beacons).

Thus, I think we will need an additional/extended interface 
mac80211<->driver here.

I see two possibilities:
a) request the next wakeup time from mac80211 each time the hardware is 
put to sleep (e.g. from ath9k_ps_restore).
b) give a whole list of periodic wakeup events of all vif to the driver. 
Then the driver is supposed to sort out the closest event.

What would be the better approach for such an interface? Or maybe a 
completely different idea?

Positive side effect: this will also enable power save when multiple 
managed interfaces are up - or combinations of different 
powersave-enabled interfaces.

Regards,
Marco


[1]
In mac80211 I removed some restrictions for mesh and basically hand the 
own STAs beacon interval to the driver (similar to ieee80211_recalc_ps).
In ath9k I merged the contents of the functions ath_beacon_config_sta 
and ath_beacon_config_adhoc with the result that beaconing is enabled 
and a power save schedule is set up.

The result is that I see an alternation of AWAKE and NETWORK SLEEP state 
with the given beacon interval period. Additionally, the log shows that 
no packets are received during the NETWORK SLEEP period, so the receiver 
seems to be actually suspended. I have not yet measured the power 
consumption though. Capturing with wireshark shows that the own mesh 
beacons are still sent regularly.
Of course, currently this breaks any connectivity when mesh PS is 
enabled. But it does not crash. And connectivity resumes when PS is 
disabled once again.

Re: [Greenmesh] [ath9k] mesh powersave hardware sleep + wakeup

[Johannes Berg]

On Wed, 2012-04-11 at 13:00 +0200, Marco Porsch wrote:

> Thus, I think we will need an additional/extended interface 
> mac80211<->driver here.
> 
> I see two possibilities:
> a) request the next wakeup time from mac80211 each time the hardware is 
> put to sleep (e.g. from ath9k_ps_restore).
> b) give a whole list of periodic wakeup events of all vif to the driver. 
> Then the driver is supposed to sort out the closest event.
> 
> What would be the better approach for such an interface? Or maybe a 
> completely different idea?

What time units would that be in, and how could you correlate them?

johannes

Re: [Greenmesh] [ath9k] mesh powersave hardware sleep + wakeup

[Marco Porsch]

On 04/12/12 06:05, Johannes Berg wrote:
> On Wed, 2012-04-11 at 13:00 +0200, Marco Porsch wrote:
>
>> Thus, I think we will need an additional/extended interface
>> mac80211<->driver here.
>>
>> I see two possibilities:
>> a) request the next wakeup time from mac80211 each time the hardware is
>> put to sleep (e.g. from ath9k_ps_restore).
>> b) give a whole list of periodic wakeup events of all vif to the driver.
>> Then the driver is supposed to sort out the closest event.
>>
>> What would be the better approach for such an interface? Or maybe a
>> completely different idea?
>
> What time units would that be in, and how could you correlate them?

I did not take an exhaustive overview over all possible drivers.
But as the current mac80211<->driver interface carries only beacon 
interval (in TU) and DTIM period, that should be a good starting point.
ath9k additionally relies on the neighbors address to check whether it 
can resume sleep after receiving an expected beacon (see setting of 
'is_mybeacon' in ath_rx_tasklet).

Concerning correlation, in mesh mode we recently have t_offset (in TSF 
increments) stored in sta_info and in client mode the drivers' 
synchronised TSF should be the reference (but I am not quite sure what 
happens when one client is associated to multiple AP).

Regards,
Marco

Re: [Greenmesh] [ath9k] mesh powersave hardware sleep + wakeup

[Johannes Berg]

On Thu, 2012-04-12 at 09:41 +0200, Marco Porsch wrote:

> > What time units would that be in, and how could you correlate them?
> 
> I did not take an exhaustive overview over all possible drivers.
> But as the current mac80211<->driver interface carries only beacon 
> interval (in TU) and DTIM period, that should be a good starting point.

Those aren't really useful at all? You need to define wakeups in
absolute terms I'd think? And you could have the TSF from the beacon,
but that itself is also useless since you need the offset.

> ath9k additionally relies on the neighbors address to check whether it 
> can resume sleep after receiving an expected beacon (see setting of 
> 'is_mybeacon' in ath_rx_tasklet).

That's IBSS only I'd think?

> Concerning correlation, in mesh mode we recently have t_offset (in TSF 
> increments) stored in sta_info and in client mode the drivers' 
> synchronised TSF should be the reference (but I am not quite sure what 
> happens when one client is associated to multiple AP).

That's starting to sound more like a solution, but even then you have a
lot of issues to resolve like when exactly is the timestamp hitting.
Keep in mind that TSF == start of TSF field, while rx_status->timestamp
== start of first symbol, which I didn't even remember when you guys did
all the Toffset things, I'm guessing they're all wrong :-)

johannes

Re: [Greenmesh] [ath9k] mesh powersave hardware sleep + wakeup

[Javier Cardona]

On Tue, Apr 17, 2012 at 7:02 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> (...)
> Keep in mind that TSF == start of TSF field, while rx_status->timestamp
> == start of first symbol, which I didn't even remember when you guys did
> all the Toffset things, I'm guessing they're all wrong :-)

I think you guessed wrong :)

http://www.mail-archive.com/devel@lists.open80211s.org/msg01552.html

+       if (rx_status->flag & RX_FLAG_MACTIME_MPDU && rx_status->mactime) {
+               /*
+                * The mactime is defined as the time the first data symbol
+                * of the frame hits the PHY, and the timestamp of the beacon
+                * is defined as "the time that the data symbol containing the
+                * first bit of the timestamp is transmitted to the PHY plus
+                * the transmitting STA's delays through its local PHY from the
+                * MAC-PHY interface to its interface with the WM" (802.11
+                * 11.1.2)
+                *
+                * T_r, in 13.13.2.2.2, is just defined as "the frame reception
+                * time" but we unless we interpret that time to be the same
+                * time of the beacon timestamp, the offset calculation will be
+                * off.  Below we adjust t_r to be "the time at which the first
+                * symbol of the timestamp element in the beacon is received".
+                * This correction depends on the rate.
+                *
+                * Based on similar code in ibss.c
+                */
+               int rate;
+
+               if (rx_status->flag & RX_FLAG_HT) {
+                       /* TODO:
+                        * In principle there could be HT-beacons (Dual Beacon
+                        * HT Operation options), but for now ignore them and
+                        * just use the primary (i.e. non-HT) beacons for
+                        * synchronization.
+                        * */
+                       goto no_sync;
+               } else
+                       rate = local->hw.wiphy->bands[rx_status->band]->
+                               bitrates[rx_status->rate_idx].bitrate;
+
+               /* 24 bytes of header * 8 bits/byte *
+                * 10*(100 Kbps)/Mbps / rate (100 Kbps)*/
+               t_r = rx_status->mactime + (24 * 8 * 10 / rate);
+       }


-- 
Javier Cardona
cozybit Inc.
http://www.cozybit.com

Re: [Greenmesh] [ath9k] mesh powersave hardware sleep + wakeup

[Johannes Berg]

On 4/18/2012 7:56 AM, Javier Cardona wrote:
> On Tue, Apr 17, 2012 at 7:02 PM, Johannes Berg
> <johannes@sipsolutions.net>  wrote:
>> (...)
>> Keep in mind that TSF == start of TSF field, while rx_status->timestamp
>> == start of first symbol, which I didn't even remember when you guys did
>> all the Toffset things, I'm guessing they're all wrong :-)
>
> I think you guessed wrong :)

Nice! FWIW, our hardware (not that the driver supports mesh now) will 
give the timestamp at the first symbol of the MPDU, so some more offset 
calculations are needed and we don't give valid timestamps today. I 
started working on this but haven't figured out HT preamble duration yet.

johannes

Re: [Greenmesh] [ath9k] mesh powersave hardware sleep + wakeup

[Javier Cardona]

On Wed, Apr 18, 2012 at 8:05 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On 4/18/2012 7:56 AM, Javier Cardona wrote:
>>
>> On Tue, Apr 17, 2012 at 7:02 PM, Johannes Berg
>> <johannes@sipsolutions.net>  wrote:
>>>
>>> (...)
>>> Keep in mind that TSF == start of TSF field, while rx_status->timestamp
>>> == start of first symbol, which I didn't even remember when you guys did
>>> all the Toffset things, I'm guessing they're all wrong :-)
>>
>>
>> I think you guessed wrong :)
>
>
> Nice! FWIW, our hardware (not that the driver supports mesh now) will give
> the timestamp at the first symbol of the MPDU, so some more offset
> calculations are needed and we don't give valid timestamps today. I started
> working on this but haven't figured out HT preamble duration yet.

Thanks for letting us know.  Now we know what hardware *not* to use for this :P

Javier

Re: [Greenmesh] [ath9k] mesh powersave hardware sleep + wakeup

[Yeoh Chun-Yeow]

Hi, Javier

> Now we know what hardware *not* to use for this
What is the hardware that you referred to?

Please advice. Thanks

Regards,
Chun-Yeow


On Wed, Apr 18, 2012 at 11:16 PM, Javier Cardona <javier@cozybit.com> wrote:
> On Wed, Apr 18, 2012 at 8:05 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On 4/18/2012 7:56 AM, Javier Cardona wrote:
>>>
>>> On Tue, Apr 17, 2012 at 7:02 PM, Johannes Berg
>>> <johannes@sipsolutions.net>  wrote:
>>>>
>>>> (...)
>>>> Keep in mind that TSF == start of TSF field, while rx_status->timestamp
>>>> == start of first symbol, which I didn't even remember when you guys did
>>>> all the Toffset things, I'm guessing they're all wrong :-)
>>>
>>>
>>> I think you guessed wrong :)
>>
>>
>> Nice! FWIW, our hardware (not that the driver supports mesh now) will give
>> the timestamp at the first symbol of the MPDU, so some more offset
>> calculations are needed and we don't give valid timestamps today. I started
>> working on this but haven't figured out HT preamble duration yet.
>
> Thanks for letting us know.  Now we know what hardware *not* to use for this :P
>
> Javier
> _______________________________________________
> Greenmesh mailing list
> Greenmesh@lists.osll.spb.ru
> http://lists.osll.spb.ru/mailman/listinfo/greenmesh

Re: [Greenmesh] [ath9k] mesh powersave hardware sleep + wakeup

[Javier Cardona]

On Wed, Apr 18, 2012 at 7:41 PM, Yeoh Chun-Yeow <yeohchunyeow@gmail.com> wrote:
>> Now we know what hardware *not* to use for this :P
> What is the hardware that you referred to?
>
> Please advice. Thanks

Johannes was just explaining that Intel wlan devices would not report
timing info in the way required for mesh synchronization.  Not a big
deal considering that they don't support mesh mode.
My comment should have been interpreted as a joke (and probably I
should have sent it off-list, sorry!).

Javier

> On Wed, Apr 18, 2012 at 11:16 PM, Javier Cardona <javier@cozybit.com> wrote:
>> On Wed, Apr 18, 2012 at 8:05 AM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>>> On 4/18/2012 7:56 AM, Javier Cardona wrote:
>>>>
>>>> On Tue, Apr 17, 2012 at 7:02 PM, Johannes Berg
>>>> <johannes@sipsolutions.net>  wrote:
>>>>>
>>>>> (...)
>>>>> Keep in mind that TSF == start of TSF field, while rx_status->timestamp
>>>>> == start of first symbol, which I didn't even remember when you guys did
>>>>> all the Toffset things, I'm guessing they're all wrong :-)
>>>>
>>>>
>>>> I think you guessed wrong :)
>>>
>>>
>>> Nice! FWIW, our hardware (not that the driver supports mesh now) will give
>>> the timestamp at the first symbol of the MPDU, so some more offset
>>> calculations are needed and we don't give valid timestamps today. I started
>>> working on this but haven't figured out HT preamble duration yet.
>>
>> Thanks for letting us know.  Now we know what hardware *not* to use for this :P
>>
>> Javier
>> _______________________________________________
>> Greenmesh mailing list
>> Greenmesh@lists.osll.spb.ru
>> http://lists.osll.spb.ru/mailman/listinfo/greenmesh



-- 
Javier Cardona
cozybit Inc.
http://www.cozybit.com

Re: [ath9k] mesh powersave hardware sleep + wakeup

[Marco Porsch]

On 04/11/12 13:00, Marco Porsch wrote:
> On 03/16/12 23:09, Marco Porsch wrote:
>>> On Fri, Mar 16, 2012 at 10:42:02AM +0100, Marco Porsch wrote:
>>>> I am trying to implement the IEEE 802.11s power save schemes in mac80211.
>
> I did some hacking and can now answer part one of my question:
> yes, beaconing and power save are not mutually exclusive with ath9k.
>
> Second question: what about power save doze and waking up for _multiple_
> neighbors' beacons?

I've again done some hacking: now waking up for multiple neighbor 
beacons in mesh mode seems to work experimentally [1].

Next step is the mesh awake window i.e. just keep awake for a specified 
time after beacon TX.
Is it possible to configure the hardware accordingly?


There are some settings concerning ad-hoc's ATIM window in 
ath9k_hw_beaconinit that look like it should be possible to use hardware 
timers for that. Unfortunately, I had no success on these. Maybe it 
requires ATIM frames (-> AR_TXCFG_ADHOC_BEACON_ATIM_TX_POLICY)?

Regards,
Marco


[1]
I maintain a list of wakeup events stored as ath9k_beacon_state. When 
doing ath9k_ps_restore, I re-configure the hardware with a slightly 
modified version of ath9k_hw_set_sta_beacon_timers to expect the next 
wakeup event.
Actually seems to work.