Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Matt,
For your first point, the AP at the anchor link can get the info of the exchange between the target non-AP MLD in non-anchor link internally within the MLD without
monitoring the link. There should be some time lag, but it can follow the recommended (should) behavior at some point. And such internal exchange is required anyway to stop transmission on other link(s) when detected on a link.
For your second point, if there’s only two links, I agree the cross link is not so complex. I commented to have some restriction on the number of multi-links. Your third point is what I anticipated as a rejection reasoning. Setting an anchor link is somewhat similar to the channel access rules for wider bandwidth based
on the primary link. The non-continuous channels being not further supported, MLO will be their substitutions and more relax transmission rules for NSTR link pairs may be favored. But if there’s a lot of “corner cases” where non-simultaneous transmission happens
to occur on one link at the same time with the other link, the gain of NSTR will disappear as normal communication can’t be achieved and it’s better to set some restrictions to the NSTR MLDs. Note that the AP MLD side still have the gain to start TXOP with
such NSTR MLDs in my proposal. From: Matthew Fischer <00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx>
Tomo, On Mon, Mar 29, 2021 at 7:57 PM <tomo.adachi@xxxxxxxxxxxxx> wrote:
The point was that: a) your proposed resolution was proposed in order to reduce the amount of cross link monitoring With an anchor link, one "only needs to check the activity on the anchor link" But this is not true. If the AP is TX a Trigger on the non-anchor link to STAx, then the AP on the anchor link might want to know this to avoid starting a DL TX to STAx on the anchor link. I.e. there is still checking of each link by the other. The goal of the proposed change is not achieved. Also, I'll change the resolution to suggest that the amount of cross link monitoring is not so difficult that reducing the links monitored from 2 to 1 would create a significant release of complexity
for an implementation. I.e. I think that the goal of reducing cross link checking is not one that most people care about. It's not a very complex operation. I'll also add to the resolution that removing the ability of a non-AP STA to be able to use the first available link reduces some of the gain of ML operation for an NSTR STA, which includes latency
reduction.
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 |