question on SMPS for AP

question on SMPS for AP

[vivekanandah]

hi,

i was looking into the MAC80211 code for Spatial multiplexing Power 
Save handling.

i see that for the station side, the code seems to be handled.
is the same true for an AP interface as well? this is my current 
understanding and i do not see any code handling for AP for SMPS.


 From the perspective of an AP, the only thing it needs to do, is to 
monitor the station for change to dynamic SMPS mode and if the station 
is in dynamic SMPS mode, set the RTS flag for the first packet to be 
sent out to the station so that an RTS/CTS mechanism is employed before 
the packet transfer. this will make the station to wake up its receive 
chains for the impending packet tranfer.

can anyone provide any inputs for the same and direct me to any code 
that will help in understanding SMPS for AP?

thanks in advance
best regards
Vivek

Re: question on SMPS for AP

[Johannes Berg]

Hi Vivek,

> i was looking into the MAC80211 code for Spatial multiplexing Power 
> Save handling.
> 
> i see that for the station side, the code seems to be handled.
> is the same true for an AP interface as well? this is my current 
> understanding and i do not see any code handling for AP for SMPS.

Which part? There are two sides to SMPS handling:
 1) changing our own SMPS mode
 2) handling stations changing their SMPS mode

1) is implemented only for station mode, 2) is implemented for both AP
and station mode (though is less relevant for station mode)

>  From the perspective of an AP, the only thing it needs to do, is to 
> monitor the station for change to dynamic SMPS mode and if the station 
> is in dynamic SMPS mode, set the RTS flag for the first packet to be 
> sent out to the station so that an RTS/CTS mechanism is employed before 
> the packet transfer. this will make the station to wake up its receive 
> chains for the impending packet tranfer.
> 
> can anyone provide any inputs for the same and direct me to any code 
> that will help in understanding SMPS for AP?

Yes this is implemented, it starts in ieee80211_rx_h_action(),
WLAN_CATEGORY_HT, WLAN_HT_ACTION_SMPS and ends by calling
rate_control_rate_update(). The driver or rate control algorithm has to
take this into account, I'm not certain that all drivers and algorithms
do this correctly (yet).

johannes

Re: question on SMPS for AP

[vivekanandah]

hi Johannes,

thanks for the response.

for the below statement:

Yes this is implemented, it starts in ieee80211_rx_h_action(),
> WLAN_CATEGORY_HT, WLAN_HT_ACTION_SMPS and ends by calling
> rate_control_rate_update(). The driver or rate control algorithm has 
> to
> take this into account, I'm not certain that all drivers and 
> algorithms
> do this correctly (yet).


i see that the rate_control_rate_update is called with the 
IEEE80211_RC_SMPS_CHANGED flag. however, i see that the minstrel_ht code 
does not check for SMPS with respect to RTS.

Also, the code - rate_control_rate_update calls - sta_rc_update 
mac80211 op. i was first thinking that i could use this for the AP side 
notification to driver layer. however, a comment for sta_rc_update 
indicates that it is to be used only when IEEE80211_HW_HAS_RATE_CONTROL 
is true.
this led to the confusion.

Can this op be used to update the driver about change in station's SMPS 
mode for AP ?

thanks and regards
Vivek


On Wed, 03 Apr 2013 10:05:19 +0200, Johannes Berg wrote:
> Hi Vivek,
>
>> i was looking into the MAC80211 code for Spatial multiplexing Power
>> Save handling.
>>
>> i see that for the station side, the code seems to be handled.
>> is the same true for an AP interface as well? this is my current
>> understanding and i do not see any code handling for AP for SMPS.
>
> Which part? There are two sides to SMPS handling:
>  1) changing our own SMPS mode
>  2) handling stations changing their SMPS mode
>
> 1) is implemented only for station mode, 2) is implemented for both 
> AP
> and station mode (though is less relevant for station mode)
>
>>  From the perspective of an AP, the only thing it needs to do, is to
>> monitor the station for change to dynamic SMPS mode and if the 
>> station
>> is in dynamic SMPS mode, set the RTS flag for the first packet to be
>> sent out to the station so that an RTS/CTS mechanism is employed 
>> before
>> the packet transfer. this will make the station to wake up its 
>> receive
>> chains for the impending packet tranfer.
>>
>> can anyone provide any inputs for the same and direct me to any code
>> that will help in understanding SMPS for AP?
>
> Yes this is implemented, it starts in ieee80211_rx_h_action(),
> WLAN_CATEGORY_HT, WLAN_HT_ACTION_SMPS and ends by calling
> rate_control_rate_update(). The driver or rate control algorithm has 
> to
> take this into account, I'm not certain that all drivers and 
> algorithms
> do this correctly (yet).
>
> johannes

Re: question on SMPS for AP

[vivekanandah]

Hi helmut,

thanks for the response.

thanks and regards
Vivek


On Wed, 3 Apr 2013 10:09:51 +0200, Helmut Schaa wrote:
> Hi Vivek,
>
> On Wed, Apr 3, 2013 at 10:05 AM, Johannes Berg  wrote:
>
>> The driver or rate control algorithm has to
>> take this into account, I'm not certain that all drivers and
>> algorithms
>> do this correctly (yet).
>
> Just as an example, in rt2x00  we just have to set one bit in the tx
> descriptor to
> force the hw to send out a 1-stream RTS to wake up the peer, from
> rt2x00queue.c:
>
>                 /*
>                  * MIMO PS should be set to 1 for
> STA's using dynamic SM PS
>                  * when using more then one tx stream
> (>MCS7).
>                  */
>                 if (sta && txdesc->u.ht.mcs > 7 &&
>                      sta->smps_mode ==
> IEEE80211_SMPS_DYNAMIC)
>                        
> __set_bit(ENTRY_TXD_HT_MIMO_PS, &txdesc->flags);
>
> HTH,
> Helmut
>
>
> Links:
> ------
> [1] mailto:johannes@sipsolutions.net

Re: question on SMPS for AP

[Johannes Berg]

> i see that the rate_control_rate_update is called with the 
> IEEE80211_RC_SMPS_CHANGED flag. however, i see that the minstrel_ht code 
> does not check for SMPS with respect to RTS.

It's very well possible that minstrel doesn't implement this correctly.
I don't care all that much right now about minstrel, so it's up to those
who do :)

> Also, the code - rate_control_rate_update calls - sta_rc_update 
> mac80211 op. i was first thinking that i could use this for the AP side 
> notification to driver layer. however, a comment for sta_rc_update 
> indicates that it is to be used only when IEEE80211_HW_HAS_RATE_CONTROL 
> is true.
> this led to the confusion.
> 
> Can this op be used to update the driver about change in station's SMPS 
> mode for AP ?

Well, in theory it could be, but it doesn't make sense. If you have a
rate control algorithm in software (like minstrel) then that should
likely configure the RTS, and rate control is updated via the rate
control rate_update() callback instead of via the driver.

johannes

RFC: SMPS for AP mode

[vivekanandah]

hi,

based on the discussion, i have come out with an RFC for SMPS support 
for AP in minstrel_ht. kindly see the explanation below and indicate to 
me, if this okay or any changes are required?

RFC To send out RTS for AP connected to a dynamic SMPS station

This code change addresses the AP requirement of sending out a
RTS frame when dynamic SMPS is enabled at the station

the minstrel_ht rate module needs to provide the lower driver layer
an indication of enabling RTS frame transmission for an AP connected
to a dynamic SMPS station.

the SMPS state of the station is stored in the ieee80211_sta 
structure's ht_cap variable.

the minstrel_ht_get_rate function can be modified to check if the 
station is a dynamic SMPS
station and a new flag can be incorporated for the ieee80211_tx_info 
flags (e.g. IEEE80211_TX_CTL_SMPS_SET_RTS)
that indicates to the lower layer that the station is a dynamic SMPS 
enabled station.

the lower AP driver can then enable RTS before the first frame 
transmission to the station by checking for the above flag.

thanks and regards
Vivek




On Wed, 03 Apr 2013 10:46:04 +0200, Johannes Berg wrote:
>> i see that the rate_control_rate_update is called with the
>> IEEE80211_RC_SMPS_CHANGED flag. however, i see that the minstrel_ht 
>> code
>> does not check for SMPS with respect to RTS.
>
> It's very well possible that minstrel doesn't implement this 
> correctly.
> I don't care all that much right now about minstrel, so it's up to 
> those
> who do :)
>
>> Also, the code - rate_control_rate_update calls - sta_rc_update
>> mac80211 op. i was first thinking that i could use this for the AP 
>> side
>> notification to driver layer. however, a comment for sta_rc_update
>> indicates that it is to be used only when 
>> IEEE80211_HW_HAS_RATE_CONTROL
>> is true.
>> this led to the confusion.
>>
>> Can this op be used to update the driver about change in station's 
>> SMPS
>> mode for AP ?
>
> Well, in theory it could be, but it doesn't make sense. If you have a
> rate control algorithm in software (like minstrel) then that should
> likely configure the RTS, and rate control is updated via the rate
> control rate_update() callback instead of via the driver.
>
> johannes

Re: RFC: SMPS for AP mode

[Johannes Berg]

Hi,

> based on the discussion, i have come out with an RFC for SMPS support 
> for AP in minstrel_ht. kindly see the explanation below and indicate to 
> me, if this okay or any changes are required?

Code talks ;-)

> RFC To send out RTS for AP connected to a dynamic SMPS station
> 
> This code change addresses the AP requirement of sending out a
> RTS frame when dynamic SMPS is enabled at the station
> 
> the minstrel_ht rate module needs to provide the lower driver layer
> an indication of enabling RTS frame transmission for an AP connected
> to a dynamic SMPS station.

It really just needs to set the RTS flag on the frames.

> the SMPS state of the station is stored in the ieee80211_sta 
> structure's ht_cap variable.

No, not any more.

> the minstrel_ht_get_rate function can be modified to check if the 
> station is a dynamic SMPS
> station and a new flag can be incorporated for the ieee80211_tx_info 
> flags (e.g. IEEE80211_TX_CTL_SMPS_SET_RTS)
> that indicates to the lower layer that the station is a dynamic SMPS 
> enabled station.
> 
> the lower AP driver can then enable RTS before the first frame 
> transmission to the station by checking for the above flag.

Sounds about right.

johannes

RE: RFC: SMPS for AP mode

[Naveenraj Subramanian]

Hi Vivek,

Do you plan to implement this piece of code?

Regards,
Naveen.
________________________________________
From: linux-wireless-owner@vger.kernel.org [linux-wireless-owner@vger.kernel.org] on behalf of Johannes Berg [johannes@sipsolutions.net]
Sent: Tuesday, April 09, 2013 3:49 PM
To: Vivekananda Holla
Cc: linux-wireless@vger.kernel.org; nbd@openwrt.org
Subject: Re: RFC: SMPS for AP mode

Hi,

> based on the discussion, i have come out with an RFC for SMPS support
> for AP in minstrel_ht. kindly see the explanation below and indicate to
> me, if this okay or any changes are required?

Code talks ;-)

> RFC To send out RTS for AP connected to a dynamic SMPS station
>
> This code change addresses the AP requirement of sending out a
> RTS frame when dynamic SMPS is enabled at the station
>
> the minstrel_ht rate module needs to provide the lower driver layer
> an indication of enabling RTS frame transmission for an AP connected
> to a dynamic SMPS station.

It really just needs to set the RTS flag on the frames.

> the SMPS state of the station is stored in the ieee80211_sta
> structure's ht_cap variable.

No, not any more.

> the minstrel_ht_get_rate function can be modified to check if the
> station is a dynamic SMPS
> station and a new flag can be incorporated for the ieee80211_tx_info
> flags (e.g. IEEE80211_TX_CTL_SMPS_SET_RTS)
> that indicates to the lower layer that the station is a dynamic SMPS
> enabled station.
>
> the lower AP driver can then enable RTS before the first frame
> transmission to the station by checking for the above flag.

Sounds about right.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html