| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Laurent, Thanks for your clarification. I don’t think it’s correct to use parts of feature to define the ETH device. For instance, ETH STA may have a feature set(1,2,3,4), what you want to say in the SP is that feature1 is a part of ETH STA feature,
it’s fine. Considering that feature1 is a not a specific feature for ETH STA, a pre-ETH STA may have an another feature set(1,5,6), it’s also can be said that feature1 is a part of pre-ETH STA feature, it’s fine as well. Therefore, I think we should use a
feature set(1,2,3,4) to define ETH STA other than use a normal feature to do it. Thanks Best Regards Jay Yang From: Cariou, Laurent <laurent.cariou@xxxxxxxxx> Thanks all, See some responses: To VK: I think the following would work
To Sai: Link refers to the channel and the 2 peers (STA and AP) so not sure it’s fully accurate, but we can use link if the group prefers. In that case that would become
To Jay: The intention here is just to mention that all those devices will be MLD and therefore will support MLD functionalities that we define. Obviously the MLD functionalities will depend on the capabilities of the devices themselves (single
radio, dual radio, STR, non-STR, …). You have to compare pre-EHT devices and EHT devices with same capabilities (single radio, dual radio, …), in that case the difference for EHT devices is that they’ll support the MLD functionalities that pre-EHT device don’t.
Hope it’s clearer. To Chunyu: We can use link if the group prefers. What we add here is a mandate for all devices that meet the conditions. Obviously, if the STA wants to be dual radio, and benefit from MLD functionalities, it will need to be supporting MLD. To Pooya: I’ll add that note to SP#2. To Patrice: Obviously, every STA affiliated with an MLD is a STA that operate with the corresponding AP with baseline rules. So EDCA is surely supported by all STAs and we don’t really need to mention that. Now for specific MLD devices, especially
dual radio devices that are non-STR, in addition to baseline channel access of each STAs, we are discussing different channel access mechanisms to improve operation (for aggregation). But this is not part of the MLO basic framework, as this is dependent on
the MLD capabilities. Thanks Laurent From: NEZOU Patrice <Patrice.Nezou@xxxxxxxxxxxx>
Hi Laurent, Thanks for initiating discussion about mandatory features related to MLO features. I have a question related to slide 3 and SP#2. I agree with you about the list of sub features. But I think that the medium access procedure has to be defined for the MLO. At least, a discussion must conclude on how a multi-link transmission
is initiated. If the conclusion is that standardized EDCA mechanism is used on each link, I am afraid that a multi-link transmission can never be started or the efficiency will be very low. So for me, the medium access subject is a key point for the MLO.
Regards. Patrice From: Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Hi all, Starting a thread for Q/A on doc 992 as we ran out of time. Feel free to ask your questions there, and refer to the SP# to which the question applies. Just posted below for reference the versions of SPs for SP1 discussed this morning:
Thanks, Laurent 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 |