| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
“The STR/NSTR mode of a non-AP MLD on a pair of setup links may change after multi-link setup”
From: Liyunbo <liyunbo@xxxxxxxxxx>
Dear all, Base on the discussion during the last MAC call, I capture below questions, and I update R8 base on questions, please further check
whether it is OK for you. Further comments are welcome. Q1:Why there is a STR Operation mode? Answer: It is not mentioned in the motion text, so I delete “operation mode”, and change to “STR/NSTR mode”. “through an Action frame”
is also deleted, which is not mentioned in the motion text. Q2: Capability will not be updated after association Answer: it doesn’t mention capability update in R8. “The STR/NSTR mode of a non-AP MLD on a pair of setup links may change after multi-link
setup” is used. Q3: Indicate STR/NSTR capability in pairwise is not efficient Answer: indicate STR/NSTR capability in pairwise is follows motion text. See Motion 38. Q4: For the case of link 1T/link 2 R is fine, and link1 R /link 2 T is not supported, why it is NSTR? Answer: it is the content of Motion 122, #SP167. The spec text follows the motion text. Q5: For the case of link 1T/link 2 R is fine, and link1 R /link 2 T is not supported, does it need further differentiated? Answer: it is not mentioned in the motion, so the spec text not mentioned it as well. My personal opinion is not necessary to differentiated
it. But if anybody think it is worth to do that, I think it can be further discussed later. Doc 1320 is not a good place to discuss it, because it is out of the scope of passed motions. The technical reason about no need to differentiate the direction of STR capability is below (see slide4 of 11-20/921r2) “Most of the transmission has a response frame (Data/Ack, RTS/CTS,…), once any direction is non-STR, PPDU end sync is required.
So it doesn’t need to distinguish which direction is non-STR. “ Regards, Yunbo 发件人:
Young Hoon Kwon [mailto:younghoon.kwon@xxxxxxx]
Hi Yunbo, I have added some comments on top of Insun’s document as attached. Thanks, Young Hoon From:
장인선 <insun.jang@xxxxxxx>
Caution:
EXT Email
Hi Yunbo Thanks for preparing the updated PDT. I have a few comments on r3 posted in the attached file. Thanks Best Regards Insun From: Liyunbo [mailto:liyunbo@xxxxxxxxxx]
Hi All, Motion 112 (#SP4) is added in 11-20/1320r2. Please further check. Hi Laurent and Dibakar, Thanks for the comments. I accept all the editorial changes. But for the comments about single radio MLD, I didn’t add it in this version.
The reason is single radio MLD is not mentioned in any motion in this document, the comments related to the details of the signaling design. So I prefer to modify or add them after the details of signaling passed the motion. Please check whether it is OK for
you. Regards, Yunbo 发件人:
Cariou, Laurent [mailto:laurent.cariou@xxxxxxxxx]
Hi Yunbo, Thanks. Some comments attached Thanks Laurent From: Sharan Naribole <n.sharan@xxxxxxxxxxx>
Hi Yunbo, Thanks for preparing document! The below motion is related to STR capability signaling after multi-link setup. Currently, it is classified
under MLO-Multi-link setup: Procedure. I think Multi-link channel access: Capability Signaling is more apt. Could you add this to your doc? I can mention this in upcoming call. 802.11be supports that a non-AP MLD may update its ability to perform simultaneous transmission and reception on a pair of setup links after multi-link setup.
NOTE – Specific signaling for update indication is TBD.
NOTE – Limitations on dynamic updating is TBD. [Motion 112, #SP4, [13] and [101]] Thanks, Sharan From: Liyunbo [mailto:liyunbo@xxxxxxxxxx]
Hello, MLO Multi-Link Channel Access: Capability Signaling TTT members and those interested in this topic I uploaded a preliminary draft on MLO Multi-Link Channel Access: Capability Signaling to the mentor. Please let me know your opinions. Regards Yunbo Li 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 |