| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Xiaofei, Thanks for your questions. We do have to discuss bit more on the details. Please see inline.
Regards, Dibakar From: Xiaofei Wang <Xiaofei.Wang@xxxxxxxxxxxxxxxx> Hi Dibakar, Thanks for presenting the PDT. I have a few questions:
1.
Any thoughts on how the UL Target Receive Power will be set in MU-RTS? This was important when the response frame is HE TB PPDU, how about in case of SU PPDU? Since there are more than 1 SU PPDUs that
will follow MU-RTS, can a STA change its transmit power, for example, when data is transmitted at a higher MCS? [Yes. The STA can select its own TX power as it would do if it transmits an SU PPDU through EDCA. So, this field can continue to be reserved as in baseline MU-RTS or repurposed for additional signaling.]
2.
I feel that we may need a bit more information in the spec text on RU allocation as well. Again, since there are more than one SU PPDUs that will follow MU-RTS, I assume that the STA must use the same
RUs as specified in MU-RTS. Currently the spec does say the CTS needs to be transmitted on that RU, I assume that in this SU procedure, it will follow the same procedure. How about the other SU PPDUs? [The other SU PPDUs that are transmitted by that STA are also transmitted within the RU. Basically, for the P2P case the STA behaves as if it had obtained a TXOP, whose limit is equal to allocated time, using EDCA. We can clarify that when
we have more details about the channel access part.] It seems that the procedure needs more details.
Best regards, Xiaofei Clement Wang Principal Engineer | InterDigital T: (631) 622.4028 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 |