On Mon, Nov 06, 2023 at 03:36:36PM +0200, Jouni Malinen wrote:
> On Tue, Aug 22, 2023 at 08:21:52PM +0530, Gokul Sivakumar wrote:
> > With "TWT_SETUP" control SOCK CMD interface currently available in the
> > wpa_supplicant, it is currently possible to generate the TWT Setup Action
> > frame with the desired TWT session params like SP, SI, TWT Setup CMD type,
> > Flow ID, Trigger/Non-Trigger based, Un-Announced/Announced session types,
> > etc, without informing the TWT state machine in the low layer.
>
> The current TWT implementation in wpa_supplicant is only for testing
> purposes, so I would like to understand what is the use case for this
> extension proposed in patch 2..7. I did apply patch 1/7 with some
> cleanup, but I'm not sure I understand what the functionality in the
> other patches would be used for and more specifically, why it would need
> to be in wpa_supplicant.
>
> It looks like this set of patches does not add any direct use of this
> into wpa_supplicant, i.e., this just defines a vendor specific kernel
> interface and a wpa_supplicant control interface to use that kernel
> interface. Why does wpa_supplicant need to be involved in that? Couldn't
> the component that would use the wpa_supplicant control interface use
> the vendor specific kernel interface directly to simplify this?
>
> --
> Jouni Malinen PGP id EFC895FA
We can understand that the current TWT implementation is a minimal testing
infrastructure, and so suggesting to improvise it through some of the changes
in this patchet. Like the newly introduced wpa_cli twt_setup cmd line arg
"twt_offset=<u64>" would be helpful to select a relative Target Wake Time,
because the userspace would not always know the current TSF to set a future
TSF in the "twt=<u64>" arg. And for backward compatibility, the existing
testing infrastructure to construct and send TWT Setup & TWT Teardown Action
frames are still preserved and can be used when CONIG_TESTING_OPTIONS=y is
set in wpa_supplicant defconfig.
As of now, not many HE Access Points initiate an Un-Solicited iTWT session
setup with its HE Capable stations after connection, even though the standard
allows it (Reference IEEE STD 802.11ax-2021 Page 389). Proabably because the
HE Access Points doesn't want to unconditinally reduce the TPUT of all of its
connected HE stations by restricting its Tx/Rx through a TWT session.
Un-Solicited iTWT Setup sequence
wpa_supplicant hostapd
HE STA HE AP
====== =====
| ----------------- connection complete ------------------ |
| |
| <<------ iTWT Setup Action (requestor:0, SP, SI) <<----- |
| (setup_cmd: Accept, other flags) |
| |
| ------- iTWT Session active b/w STA & AP, if STA ------- |
| didn't send immediate iTWT Teardown Action |
So after successful connection with the HE AP, the HE STA has to proactively
Solicit for an iTWT session setup to take advantage of its TWT capability for
Scheduled Tx/Rx, Power Saving, or other reasons. But wpa_supplicant doesn't
have a mechanism to properly initiate TWT Setup or Teardown as the testing
infrastructure would just blindly construct the Action frame and transmits it.
Solicited iTWT Setup sequence
wpa_supplicant hostapd
HE STA HE AP
====== =====
| ----------------- connection complete ------------------ |
| |
| ------>> iTWT Setup Action (requestor:1, SP, SI) ----->> |
| (setup_cmd: Request, other flags) |
| |
| <<------ iTWT Setup Action (requestor:0, SP, SI) <<----- |
| (setup_cmd: Accept, other flags) |
| |
| ------- iTWT Session active b/w STA & AP, if STA ------- |
| didn't send immediate iTWT Teardown Action |
The submitted patchset equips wpa_supplicant for initiating a TWT session setup
or tearing down an already established TWT session. With this capability ready,
next we can enhance it further by introducing support in wpa_supplicant.conf
for the user to set the iTWT session parameters like Service Period (SP),
Service Interval (SI), Session types Announced/Un-Announced, Trigger/Non-Trigger
based, Implicit/Explicit, etc. Then when the Solicited TWT session is enabled,
wpa_supplicant can initiate a TWT session setup after connection with HE AP, by
invoking the same function that is used when "$ wpa_cli twt_setup" is triggered.
I could submit these changes for review as a followup.
IMHO, since HE STA's wpa_supplicant is initiating and managing the connection
with the HE AP, it is appropriate for wpa_supplicant to have the capability to
Setup and Teardown an iTWT session after connecting with the HE AP.
Gokul
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
