Hi Yunbo,
Thanks for initiating the email discussion.
I think there is a difference of understanding among us on the capabilities of an EMLSR non-AP.
You seem to be assuming the following for an EMLSR non-AP:
It requires a switching delay for all of the following transitions.
(Listen -> Receive) and (Receive -> Listen)
(Listen -> Transmit) and (Transmit -> Listen)
It becomes blind on one link during all of the above transitions and also during either Receive or Transmit.
This is a very conservative assumption. The EMLSR specification too does not mandate such blindness. I have explained my understanding below.
Untriggered UL transmissions: It is very much possible to have EMLSR architectures where the non-AP will not require any switching delay, either for (listen -> transmit) or (transmit->receive). So, there is no blindness unless the UL PPDU duration is > 72us. Note that the EMLSR specification too does not define any switching delay for untriggered UL transmissions.
DL transmissions: It is very much possible and allowed by the specification to have EMLSR architectures where the non-AP will not have any blindness during DL, except for transmissions of CTS/BA which can typically be <72us. As an example, I have drawn below a DL frame exchange and marked the instances where an EMLSR non-AP may require switching delays and EMLSR blindness.
From the above it is observed that the EMLSR non-AP,
Is blind on link2 only during transmission of CTS and BA. However, since both of these can be < 72us, the EMLSR non-AP need not perform any blindness recovery.
Requires a delay (t2-t1) to switch from (listen->receive), but is not blind on any link (either link1 or link2) during the switch.
In a less capable non-AP architecture, the EMLSR non-AP may become blind for a sub-interval of [t1, t2], but it does not have to perform blindness recovery if this sub-interval is < 72us and the non-AP is able to listen on link2 during [t2, t3].
Does not require any delay to switch from (receive->listen) at the end of DL frame exchanges.
Triggered UL transmissions: Is similar to DL, except that if the UL PPDU duration > 72us, the EMLSR non-AP will become blind and has to perform blindness recovery. This will be applicable for NSTR too.
That is why I had mentioned during the call yesterday that since an EMLSR non-AP has 2 receive chains it is very much possible to have EMLSR architectures where the non-AP does not have any additional blindness over what is present for an NSTR non-AP.
Regards,
Shubho
Hello Yunbo,As I commented during the call, you are not doing apple to apple comparison. A NSTR MLD has two fully capable radios (two independent PHY/MAC blocks) whereas a single radio non-AP MLD operating in EMLSR has one fully capable radio. The NSTR MLD is close to double the complexity/cost of the non-AP MLD that has the EMLSR capability. The complexity/cost has to be considered in the comparison.Another observation is that a NSTR non-AP MLD with two 1x1 radios is actually less spectral efficient than 2x2 non-AP MLD in EMLSR mode since the NSTR non-AP MLD is using two 80 MHz links with 1ss on each link whereas the non-AP MLD in EMLSR mode is using one 80 MHz link with 2ss. For a busy network environment with many OBSSs that are not synchronized on both links (i.e. busy/idle are not synchronized on both links), this becomes a bigger problem to the NSTR non-AP MLD since most of time the two links are not idle at the same time and only 1ss can be used on one idle link whereas for the non-AP MLD in EMLSR mode it can still use 2ss on one idle link.I also couldn't understand clearly why delay results are so high. There will be many cases where a STA can sync to the medium by receiving a frame from its own BSS or OBSS, by transmitting an RTS based on the current 11be spec, perform CCA if a STA is not doing 2ss tx, soliciting uplink traffic with a trigger frame, etc.Regards,MinyoungOn Wed, Mar 23, 2022 at 9:48 AM Liyunbo <00001846a2e5e0c1-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:Dear all,
Thanks for your discussion during the presentation. I initiate this email thread to further discussion for doc 22/349. Please let me know your questions and comments if you don’t have time to express them during the call.
Here are some response to Minyoung and Shubho’s questions.
Q1: Whether switch delay of EMLSR affect the blindness in UL short PPDU transmission?
A1: when EMLSR MLD do UL transmission on link1, whether link 2 will enter blindness mode depends on the total duration of switch delay period and UL PPDU length. Assuming the UL PPDU length is 50 us, a 22 us switching delay (22+50=72us, which is the duration of MediumSyncThreshold) will trigger link 2 enter blindness mode. So you can see that link 2 will enter blindness mode even it is a small switching delay and short UL PPDU.
Q2: For blindness, can EMLSR be same as NSTR?
A2: No. For DL data transmission, NSTR will not enter blindness mode because most BA will shorter than 72us. But EMLSR will enter blindness for sure, because the initial control frame exchange already larger than 72us. For UL short packet transmission, NSTR will enter blindness when UL PPDU length >=72us, while EMLSR will not enter blindness when UL length >= (72-swithing delay). Consider the PHY preamble and switching delay, you can see that EMLSR will very easy to enter blindness even for short UL packet.
Q3: Why complexity is not considered in the presentation?
A3: The main purpose of this presentation is to show the performance of EMLSR and NSTR. Because performance is a very important factor for people to judge a feature. For complexity, I don’t think it is an easy to compare, it relates to a lot of implementation details. Here I want to point out one more benefit of NSTR. There are full radios on both links for NSTR, so it is very flexible for a non-AP MLD to operate as STR (when AP MLD set up two links with enough frequency gap) or NSTR (when AP MLD set up two links very close). But EMLSR MLD can not switch between STR and EMLSR even AP set up two links with enough frequency gap.
Regards,
Yunbo
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