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
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
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
On Wed, Apr 18, 2012 at 7:41 PM, Yeoh Chun-Yeow <[email protected]> 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 <[email protected]> wrote:
>> On Wed, Apr 18, 2012 at 8:05 AM, Johannes Berg
>> <[email protected]> wrote:
>>> On 4/18/2012 7:56 AM, Javier Cardona wrote:
>>>>
>>>> On Tue, Apr 17, 2012 at 7:02 PM, Johannes Berg
>>>> <[email protected]> ?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
>> [email protected]
>> http://lists.osll.spb.ru/mailman/listinfo/greenmesh
--
Javier Cardona
cozybit Inc.
http://www.cozybit.com
On Wed, Apr 18, 2012 at 8:05 AM, Johannes Berg
<[email protected]> wrote:
> On 4/18/2012 7:56 AM, Javier Cardona wrote:
>>
>> On Tue, Apr 17, 2012 at 7:02 PM, Johannes Berg
>> <[email protected]> ?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
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
On 4/18/2012 7:56 AM, Javier Cardona wrote:
> On Tue, Apr 17, 2012 at 7:02 PM, Johannes Berg
> <[email protected]> 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
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.
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.
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 <[email protected]> wrote:
> On Wed, Apr 18, 2012 at 8:05 AM, Johannes Berg
> <[email protected]> wrote:
>> On 4/18/2012 7:56 AM, Javier Cardona wrote:
>>>
>>> On Tue, Apr 17, 2012 at 7:02 PM, Johannes Berg
>>> <[email protected]> ?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
> [email protected]
> http://lists.osll.spb.ru/mailman/listinfo/greenmesh
On Tue, Apr 17, 2012 at 7:02 PM, Johannes Berg
<[email protected]> 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/[email protected]/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
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
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