| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello All, I presented last Monday document 11-21/1686r0 (CR for Low-Latency stream identification). This document demonstrates the requirement to finely identify data units related to latency sensitive streams, especially for an SCS contract well characterized by TSPEC and TCLAS as per 35.3.21 . This SCS stream identification is useful
for accurate reporting of BSR, for restricting the triggering to SCS stream (TF triggers accurate size according to the contract or adapted to received BSR) or even for rTWT (specify the SP is for given SCS(s) ). Thanks to the members who provided appreciated feedback during the call. I notice still remaining members in the queue: Chunyu, Jay, Muhammad, Dibakar, Liangxiao, Boyce, Yonggang, Xiaofei. Anyone interested in this topic, please feel free to provide any comment in this thread or contact me individually if you prefer. In addition, please see some answers to comments received through the chat:
-
Topic about SN of MPDUs: “STA may still not be able to transmit MSDUs for that SCSID because it needs to transmit MSDUs according to SN “ -> if the STA is not able to send MSDUs that have higher priority, especially those of negotiated rTWT between AP and STA, the STA will also send data units (not-LL stream or other local LL stream belonging to another rTWT
deadline contact) that are not in the rTWT contract during a rTWT SP. Thus QoS is broken, due to this unfairness. The rTWT is no longer “restricted”. -> I am of opinion that out-of-sequence delivery is already present for multi-link transmission; what is the special issue here ? -> In addition, if MSDUs are to be strictly transmitted in sequence, a single erroneous MSDU/MPDU (e.g. worst case if non-LL stream) will break the delivery to upper layer (re-ordering buffer at recipient), so that already
arrived LL data units suffer from HOL issue and misses its deadline. -> In addition, one may consider that low latency traffic can benefit from aging mechanism to avoid outdated packet to be sent or retransmitted. In that case, SN
delivery sequence is also impacted.
-
Topic about increasing the number of TIDs : “Only 8 TIDs are typically used, but there can be up to 255 SCSIDs”, “simplest approach is to open up TID 8-15”, “do we need to define the EDCA parameter for TID 8-15
accordingly”…” define how to map TID 8-15 to AC ?” -> IMHO, changing the EDCA with adding a bunch of new TIDs seems too complicated, for medium access point of view.
I expect using SCSID for packet classification at emitter side for LL data units is the same concept as building A-MSDU. If implementation only considers TID and destination for building A-MSDU , then the fairness issue
of mixing any MSDU belonging to a TID remains. In case SN ordering could be an issue, triggering with SCSID would just mandate assigning sequence number upon transferring A-MSDU/MPDU frame to affiliated STA, without any change in EDCA. SN assignment is still discussed
in the group (11-21-1111).
-
Using SCSID in TF is an easy means for the AP to select appropriate STA(s) for communication, with a desired allocated RU size. There is no issue at AP as it only respects the contract scheduling. As a result, AP at least expects
the STA will also limit the data units corresponding to the intended LL flow.
-
SCSID size in “Trigger Dependent User Info” subfield : as per slide 7 of the document, the original SCSID is 8 bits SCSID, whereas the room as illustrated is 5 bits. This illustration is provided with HE variant, maybe EHT variant
User Info can have a dedicated ‘trigger dependent User Info’. Other way would consist of limiting to less bits, as 256 SCSIDs is large enough per STA (32 enough ?).
-
Location of SCSID subfield in TWT IE (slide 8) : it appears ‘Restricted TWT Traffic Info’ field is better, as there is room here for 1-byte (received a comment that this is no longer the case in ‘Broadcast TWT Info’ field). SCSID
subfield and DL/UL TID subfields will therefore be mutual exclusive. Thank you, Best regards, Pascal 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 |