| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi all, What we are debating is how to resolve the highlighted TBD in the approved motion text:
“In R1, 802.11be shall define a mechanism for an AP to transmit a modified MU-RTS Trigger frame that allocates time within a TXOP for transmitting one or more non-TB PPDUs. • The time allocation starts after the end of transmission of the MU-RTS frame.
•
It is TBD whether the AP can optionally not solicit CTS. • This is an optional mechanism for non-AP and AP STAs.
NOTE – The non-TB PPDUs may be transmitted by the non-AP STA to AP or to a peer of a peer-to-peer link. “ In the PDT we propose to resolve this by not including the above text which means scheduled STA follows the baseline procedure of sending a CTS frame as response to the MU-RTS frame before sending other SU PPDUs within its allocated time. While I agree that having the CTS as always the first frame in response to the modified MU-RTS has an additional overhead, its not really a significant overhead. Within a typical allocation of the order of 1-2 ms, the overhead is of SIFS+CTS
transmission time i.e., ~(44us-60us) per allocation which is really small (e.g., ~5-6% in an allocation of 1ms) . On the other hand keeping the CTS transmission rule has following benefits:
1.
AP and STA implementations can keep the baseline MU-RTS/CTS state machine upto the CTS transmission/reception event.
2.
Provides more time to the STA to prepare its SU transmission.
3.
STA can select potentially low power to talk to its peer STA without worrying whether the AP can detect this frame and set NAV accordingly.
4.
AP gets an explicit confirmation of its allocation instead of depending on unreliable PPDU transmissions between P2P STAs. So, on balance, the benefit of keeping the baseline CTS transmission rule from 11ax seems far more than the overhead issue. Hence, it looks to me that it is better and simpler to not have the highlighted text in the spec for R1. But to
get the group’s feedback, we can run a SP on it. Regards, Dibakar From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Hi Dibakar, I understand your concern that the CTS can be used as a confirm frame to notify the AP that the STA will use the reserved TXOP to send out P2P traffic. Actually, the AP can determine whether the STA can use the reserved TXOP via medium detection, that’s, if the AP detect the medium busy after SIFS interval, It means the P2P traffic is ongoing. Otherwise, the AP will regain the TXOP since the expected STA didn’t send out P2P traffic. Therefore, the CTS is not necessary and become a burden of increasing the timing cost of exchange sequence to
P2P case. Further, the motion mentions that the non-TB PPDUs will be used for UL traffic as well, That’s to say, the STA needs to send out a CTS first before the UL traffic after receiving the variant MU-RTS, it’s a very strange behavior compared
to the basic trigger frame, I’m curiously to ask why the basic trigger frame doesn’t solicit CTS frame in 11ax, hope some expert can explain the history. I prefer the solicited CTS is optional so that it’s become a flexible behavior and different implementer can choice the suitable behavior.
Welcome further comments on this point. Thanks Best Regards Jay Yang From: Arik Klein <arik.klein@xxxxxxxxxx>
Hi Dibakar, Thanks for sharing the PDT. I’m fine with the resolution. BTW – the Abbreviation TS is already used in 802.11-2020 for Traffic Stream. Suggest to use TXS for “TXOP Sharing”. Regards, Arik From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Arik, I added an entry in EHT MAC Capabilities for this feature. Can you please take a look and see if its fine ? I will upload r4 later tomorrow.
Regards, Dibakar From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Arik, Thanks for sharing an example. I was not aware we could make changes like this. But since there is a precedent, we can do the same here as well. I will upload a new revision then.
Regards, Dibakar From: Arik Klein <arik.klein@xxxxxxxxxx>
Hi Dibakar,
·
There is one comments and some corrections in the doc (use Track changes function)
·
I agree that currently in the 802.11be D0.3 there is only a place holder for the 9.4.2.295cEHT Capabilities element. However in other PDTs that also has related fields that should be contained in the
EHT Capabilities element (i.e. 131r1)
– these changes are included in the PDT.
·
Actually, if you will not include this in your PDT, how other members will be aware that there is new field that should be included in the EHT MAC/PHY Capabilities?
Regards, Arik From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Arik, Thank you for the comment. I notice only one comment about adding an entry in the EHT MAC Capabilities for this feature.
I checked section
9.4.2.295cEHT Capabilities element and found it does not have any
text. At the same time, I realize that there are members working to bring a PDT that fills in the details for that section. As such, I would prefer to defer any changes to EHT Capabilities section until that section is bit stabilized. Would that work for you
? Regards, Dibakar From: Arik Klein <arik.klein@xxxxxxxxxx>
Hi Dibakar, Sorry for the late respond, but since the discussion on 11-21/0087r3 has not been completed yet, I hereby attach my additional comments. Thanks for your respond. Regards, Arik From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Yunbo, Regarding first item, this touches on channel access part. The details on channel access are not included in this PDT since it would deviate more from the motion text. However, we eventually in a follow-up PDT would need a way to signal
in the MU-RTS frame whether the allocation is for UL only or P2P traffic. Note that we did list them as options in 1312r5.
Regarding the second item, the question is essentially on whether we can find a better term to describe
the purpose of this modified MU-RTS frame. If you can think of a better word than “TXOP Sharing”, please let me know.
Regards, Dibakar From: Liyunbo <liyunbo@xxxxxxxxxx>
Hi Dibakar, Thanks for updating the PDT text. “During this allocated time, the non-AP STA may transmit non-TB PPDUs to its associated AP or another STA”. non –AP STA may have buffered traffic for different AP/STAs at the same time, I still
think it should allow AP have right to control which type of traffic the allocated time is for. For the name of MU-RTS Txop sharing Trigger, how about simple use “SU-RTS Trigger” which already can distinguish it from MU-RTS.
Regards, Yunbo 发件人:
Das, Dibakar [mailto:dibakar.das@xxxxxxxxx]
Hi all, Based on the feedback received during the call, I updated the document to r3. I tried to address most of the comments. Please take a look and see if you are fine with the changes.
Note that it is implied that the channel access needs to be defined and will be addressed in a follow-up document. As such, we can address the comments that are related to it at a later date.
Regards, Dibakar From: NEZOU Patrice <Patrice.Nezou@xxxxxxxxxxxx>
Hi Dibakar, Thank you for your proposal. I have several remarks and questions related to your document 82r2:
·
About the mandatory CTS sent after the TS TF, I don’t understand why it is now mandatory. I think that the TS TF should be considered as a new TF. Using the existing MU-RTS frame creates misunderstandings between legacy STAs and
11be STAs. So I think it is better to reserve a new value for the “Trigger frame variant“ field and define a new format.
·
When a STA is polled by the AP, the STA shall use a non-TB PPDU. First, the word “non-TB PPDU” is not defined until now. Then the length of the non-TB PPDU is provided by the AP. If the length is too long, what is the behavior
of the STA? How do the AP know when the transmission of the STA is done. A good solution could be that the STA sends another frame to the AP just after sending its non-TB PPDU. This allows the AP to resynchronize and to retrieve its TXOP.
·
In the subclause 35.2.1.3.1, there is an inconsistency: a TDB field remains although you have defined this field in the subclause 9.3.1.22.5. Regards. Patrice From: VIGER Pascal <Pascal.Viger@xxxxxxxxxxxx>
Hi Dibakar, Thank you for your presentation. I noticed that the latest revision adds the mandatory answer of CTS frame (no longer TBD). I understand that this is mostly a consequence of the usage of the legacy MU-RTS trigger frame that is basically
used with this obligation by 11ax (11ax devices expect to see a CTS answer). Nevertheless, it may appear that such CTS protection provides only an overhead for the Triggered TxOP sharing procedure, as an AP is always obliged to used it whereas the AP could
have determined this is not mandatory in some cases. In addition, as stated by some commenters, by deciding to re-use the MU-RTS TF, aspects dealing with the TXOP holder could be misunderstood by legacies. This is why I would suggest using a new TF type for the TS TF (it is not a big deal to have a distinct TF that solicits a SU PPDU as MU-RTS does), as you will no longer be dependent of any expected
behaviour of MU-RTS TF usage by 11ax legacies. Moreover, in your document section “35.2.1.3.3 Non-AP STA behaviour”, it seems the sentence “the STA shall transmit one or more non-TB PPDUs
“ becomes now erroneous with the latest introduced modification, as the first PPDU shall be a CTS : thus, the STA shall transmit “two or more non-TB-PPDU”, the first being the CTS. Please consider only this comment if you keep the MU-RTS format J. Thanks, Best regards, Pascal From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Hi Dibakar, I have two comments on your PDT. The first one is about the term of TXOP sharing, which is same to Yunbo’s comment, and I’m glad to see Yunbo propose new term. The second one is the deleted sentence “ It’s TBD whether the AP can optionally not solicit CTS as response to the TS trigger frame ”: One concern is same to Jarkko’s comment that the TXOP holder hand over process may be not correct if
the TS trigger frame solicit CTS frame as response. As you know, the TXOP holder hand over process is AàB or AàB,AàB mode according
to 11ax SPEC, we don’t define AàBàB mode as a new TXOP holder handover process. Another concern is that it’s no need to solicit CTS if the TS TF is designed for P2P traffic,
although you mentioned some group member solid the MU-RTS/CTS exchange process. Anyway, I understand the TS TF is only defined for EHT STA without the burden of compatible with pre-11be STA, so 11be STA can sends out the SU PPDU to another STA immediately
once getting the TXOP from AP MLD. Thanks Best Regards Jay Yang From: Liyunbo <liyunbo@xxxxxxxxxx>
Hi Dibakar, Thanks for the presentation. Below are my comments:
1)
“During this allocated time, the non-AP STA can transmit non-TB PPDUs to its associated AP or another STA.”
The sentence imply that it is the non AP STA’s choice about how to use this allocated time. The time is allocated by AP, AP should have the control how to use it. So either add some indication for the purpose of the allocated time, or modify the sentence to
make it open for further discussion.
2)
“TXOP sharing” is an existing term, it is better to use a different name before run the motion. I will feedback to you if I get a name for it.
3)
“GI And HE-LTF Mode subfield” is used in 9.3.1.22.5, but “TBD subfield” is used in the 3rd paragraph of 35.2.1.3.1. Regards, Yunbo 发件人:
Das, Dibakar [mailto:dibakar.das@xxxxxxxxx]
Hi all, Thanks for the good discussion on 87r2 today. We will follow up offline with the members who raised the question. Others please ask your questions on this thread so that we can try to address them. I noted Yunbo, Jay, Pascal, Chunyu (?), Xiaofei did not get the chance. Regards, Dibakar From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Alfred, The PDT contribution 0087r0 was next in queue for Thursday but not presented due to lack of time. However, its marked as green.
Can you please schedule it for the agenda tomorrow ? Regards, Dibakar From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Hello all, I uploaded an updated version of the agendas, which contains the agenda for the next conference calls, scheduled on Monday, February 08 (MAC/PHY), 10:00-12:00
ET. The agendas can be found here: DIAL IN DETAILS FOR MONDAY: Join the MAC meeting here:
https://ieeesa.webex.com/ieeesa/j.php?MTID=m0a0a9cac185f64cce900514e8966e029
Meeting number: 179 045 1588 Meeting password: wireless (94735377 from phones and video systems) Join the PHY meeting here:
https://ieeesa.webex.com/ieeesa/j.php?MTID=m974d0a1712c60e96e275d9e504af8977 Meeting number: 179 596 9157 Meeting password: wireless (94735377 from phones and video systems) Please let me know if you have any questions and/or clarifications. Best Regards, Alfred -- Alfred Asterjadhi, PhD IEEE802.11 TGbe Chair, Qualcomm Technologies Inc. Cell #: +1 858 263 9445 Office #: +1 858 658 5302 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 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
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 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 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 |