| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Dibakar, I am still thinking the latency sensitive mechanism is not working, because we have 2 independent mechanisms: -
You have, in one hand, SCS that is perfectly tuned to characterize the traffic. SCS request is seen as a traffic admission for a contract between STA and AP. Currently, for
UL or Direct link, there is no means for the AP to trigger data of that LL flow to honour its contract (802.11be 35.3.21 Multi-link SCS procedure: The QoS Characteristics element is a reference for the EHT AP’s scheduling. …An EHT AP
should enable the transmission of uplink frames from the EHT STA with an interval that falls between the requested minimum and maximum service intervals and the AP should meet the minimum data rate requested if the Direction subfield of the QoS Characteristics
element indicates uplink.)
è
This is why I propose that TF
may trigger an SCS stream (AP can schedule TF according to the contract, and the STA can verify the respect of the SCS contract) (note that this precise triggering may also be used inside a SP like rTWT) -
You have, in other hand, restricted TWT : Note that section 35.7.2.1 indicates that “this subclause defines a mechanism that differentiates latency sensitive traffic from
other types of traffic.”, but it is empty subclause. TWT is currently associated with a TID, therefore the service is based on User Priorities. One may think the bundle SCS+rTWT is the ideal solution for latency sensitive data… BUT there is no relation between SCS and TWT, except a general purpose TID (or User Priority). That means, as you said, that several low latency flows of same TID/UP priority would create one or several rTWT agreements, but we are not able to qualify what is currently transmitted
inside a rTWT SP (probably a mix of everything from one TID ! ). In addition, you said that an AP implementation could be able to revoke either an SCS or a rTWT (which one in fact?), if it analyses UL-received data as not latency sensitive (due to
“cheating” STA). I think this is not satisfactory. This is why I proposed the possibility to indicate an SCSID in rTWT IE (as mutual exclusive to TID bitmaps). Therefore, the STA is able to decide, according to its current implementation possibilities, if it wants a general purpose rTWT based on TID or an rTWT based on SCS. In my opinion, current STA implementation shall not restrict the future features of the standard, in contrary, the standard aims to drive implementations towards more efficient mechanisms. Having well considered that some implementations could not yet deal with SCS, I have proposed both options (TID bitmaps and SCSID) in rTWT IE (9-689c—Traffic Info Control field format),
so that STA negotiates rTWT according to its possibilities. This thus opens the way for more advanced STAs that will better manage their low latency flows (no further change in format for this purpose). As a result, there would have no longer “cheating” STA
J Best regards, Pascal From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Stephane, Lets consider UL traffic. Say, we don’t have any SCSID in a TWT IE but there is just mapping of TIDs to indicate which TIDs are prioritized in an SP.
Now, when that corresponding SP arrives and the AP sends a TF to the STA soliciting UL Data, the STA prioritizes, by itself, which streams to choose packets from. If there are MSDUs belonging to a stream with low latency
bound, then by its own selfish strategy its going to prioritize that. It can also make a bad decision and prioritize streams belonging to different stream in which case its going to penalize its own QoS because of bad implementation logic.
So, since how the STA prioritizes among MSDUs that map to same TID is based on own internal, selfish logic, having an additional signaling from AP to tell the STA what to transmit should not change its outcome.
Regarding your second question below, by AP’s expectation you mean that AP sends the TF thinking the STA would send packets belonging to high priority SCS-1 but instead STA is transmitting something else. If that’s the
concern, it is related to how the AP polices whether STAs are really using the r-TWT SP for low latency or not. This is largely an implementation choice at the AP. If the AP is not constrained for resources, then sometimes the STA’s cheating is not going to
matter much. Otherwise, the AP can use internal tools, (e.g., match statistics of MSDUs transmitted in UL with the expected SCS flows) and decide to terminate that STA from the SP.
Regards, Dibakar From: BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>
Hi Dibakar, I understand your point, but If there is no SCS identifier in the TWT IE, how does a station make a link between a given rTWT SP and SCS streams negotiated during SCS setup ? I think the AP scheduling policy will take into account the streams information coming from the STAs, but if the AP does not indicate some information about the expected traffic in a given rTWT, stations will not follow
AP’s expectation and its scheduling becomes useless. Regards. Stéphane. From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Stephane, I agree during the TWT SP, a STA should prioritize own traffic to AP or vice versa based on the parameters obtained during SCS stream setup (e.g., latency bound, PDR etc.). The action here is likely about picking for
transmission the MSDUs belonging to high priority SCS streams over low priority SCS streams that map to same TID, or picking MSDUs with high priority TIDs over low priority ones etc. However, it seems to me the STA should make the above decision regardless of whether an SCSID is included in the TWT IE. It already has the necessary information from SCS setup. So,its not clear to me how
adding more information to the TWT IE helps in this regard. Regards, Dibakar From: BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>
Hi Dibakar, I think one important related action that can be taken by a station during an rTWT SP is the data selection. In my opinion, a STA should take into account the SCS stream negociated for a given rTWT to select the data for transmission during the corresponding rTWT SP. This is why adding a finer traffic identifier, like SCS, in the rTWT IE is a good point. Regards. Stéphane. From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Mostly, TXOP level actions such as Sending TF to solicit PPDUs for particular SCS stream, or DL packets belonging to a particular SCS stream etc. From: Liangxiao Xin <xlx20190808@xxxxxxxxx>
Hi Dibakar, Thank you so much for the response. When you say R-TWT related actions, what are they? Do you mean, for example, negotiation of R-TWT SP parameter setting such as start time, interval, duration or any actions that AP/STAs take during R-TWT SP? Regards, Liangxiao On Thu, Nov 18, 2021 at 9:30 AM Das, Dibakar <dibakar.das@xxxxxxxxx> wrote:
-- Liangxiao Xin Sr. Applied Research Engineer - Wireless Sony Corporation of America To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |