Skip to content

Draft: changes to allow Wi-Fi rate control to support peek operations and to skip TXOPs

Tom Henderson requested to merge tomhenderson/ns-3-dev:wifi-skip-txop into master

I would like to get some review/feedback from Sebastien and Stefano (and anyone else interested) on proposed changes to Wi-Fi rate control's main API.

Currently, WifiRemoteStationManager (the base class for all rate controls) implements two public methods, GetDataTxVector() and GetRtsTxVector(), which return a WifiTxVector for use, typically by the frame exchange managers.

There are two limitations with this:

  1. The API does not allow for the rate control to decline to use a TXOP-- there is no way to return a null value. This hasn't been needed yet, but as we move towards coordinated spatial reuse use cases, there will be situations in which an AC wins a backoff, but the rate control decides not to use the TXOP, possibly because of interference concerns or it is in a power-restricted mode. Therefore, it would be nice to be able to return a null value.

  2. Sometimes, this API is used not for fetching a WifiTxVector for actual frame transmission, but to peek at what value will be used next. The HeRrMultiUserScheduler uses it this way, for example. However, from the perspective of the rate control, it cannot distinguish between these uses, and may lead to broken assumptions about the value that will be returned in the next call to the method, and may lead some rate controls to incorrectly count usage of WifiTxVector instances.

I have been looking at using std::optional<WifiTxVector> as a replacement return value for these methods, and also at providing a Peek variant to our Get variants (by default, the Peek would call Get, but could be overridden in subclasses). This should not affect user API but would break a lot of internal Wi-Fi API; this draft MR just takes the first initial step of such a change.

In conclusion, the main proposal is to allow null WifiTxVectors to be returned from these methods, and make the calling methods robust to a null value. The API change would be:

-    WifiTxVector GetDataTxVector(const WifiMacHeader& header, uint16_t allowedWidth);
+    std::optional<WifiTxVector> GetDataTxVector(const WifiMacHeader& header, uint16_t allowedWidth);

-    WifiTxVector GetRtsTxVector(const WifiMacHeader& header, uint16_t allowedWidth);
+    std::optional<WifiTxVector> GetRtsTxVector(const WifiMacHeader& header, uint16_t allowedWidth);

+    std::optional<WifiTxVector> PeekDataTxVector(const WifiMacHeader& header, uint16_t allowedWidth);

+    std::optional<WifiTxVector> PeekRtsTxVector(const WifiMacHeader& header, uint16_t allowedWidth);

The DoGet...() variants would also change in this way.

Opinions on proceeding with this?

Merge request reports