[PATCH v3 2/7] TWT: Add support to offload TWT Session setup handling work to the driver

[Gokul Sivakumar]

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