| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Dmitry, Thanks for your response. It is a good question, what’s the main factors that cause large differences between NSTR and EMLSR. It may need more time to do the analysis.
A simple reason may be larger overhead may cause the EMLSR to enter middle or high load much early than NSTR, and then higher collision overhead in middle/high traffic load will
further reduce the throughput. From current results, you can see that it is not always ~50% difference in DL throughput. There is no different for 0.3Mbps, a little bit low (~17%) for 1Mbps, and then 47% for 3Mbps,
61% for 10Mbps, 56% for 30Mbps, 55% for 100Mbps. You can see that the difference start to diminish after 30Mbps. It may because the percentage of airtime of overhead of EMLSR will reduce after a threshold. Regards, Yunbo 发件人: Akhmetov, Dmitry [mailto:Dmitry.Akhmetov@xxxxxxxxx]
Yunbo, thanks a lot for the reply. You explanation (i.e. 1 second of simulation time and some “tails/leftovers in TX buffer” ) would work if we were talking about 1-2% difference. But we are talking about ~25Mbps difference in delivered throughput DL direction for 3Mbps case. ~25Mbps eMLSR vs ~50 Mbps NSRT in DL direction or about 50% difference . Yunbo, 50%, not 5%, not 2% but 50%. Half of
DL traffic sit buffered in the TxQueue and . This is not “tails”, this is actually full solid “body” of input traffic in amount of ~25Mbps
This situation is quite the same across all loads – 1Mbps, 3Mbps, 10Mbps, 30 and 100Mbps. In all cases eMLSR is on par with NSTR, but DL is about 2x less that DL of nSTR That does not seem right, neither for small/tiny loads of 1Mbps/3Mbps nor for large once (10/30/100Mbps) Dmitry From: Liyunbo <liyunbo@xxxxxxxxxx>
Hi Dmitry, Thanks for your further question. Please see my response in-line. Regards, Yunbo 发件人: Akhmetov, Dmitry [mailto:Dmitry.Akhmetov@xxxxxxxxx]
Yunbo, thanks a lot for you reply. The point of my calculations was to show that this minor load shall be delivered no matter of overhead. In you results DL part AP is smaller than UL, so it is AP struggling to deliver data. Your AP has 8 streams to
8 devices. Even if AP cannot organize effective MU MIMO transmission (BTW, why MU MIMO at a first place?) it still can send data to 2 STAs at a time to 2 STAs on 2 links. Also, even if AP cannot deliver a particular frame within 4ms (or within 12ms) interarrival
time to a particular STA, it simply mean that at one of the next TX opportunities AP simply send an aggregation of 2 packets to that device. And if for some reasons AP still cannot deliver data to that STA, at one of the next opportunities it will attempt
an aggregation of 3 MPDUs. I can assure you that even in a case of simple single link traditional WiFi (i.e. .11ac, .1ax or even .11n) all traffic can be delivered in a scenario with total offered load of 30/90Mbps load. As I said, incoming traffic will be buffered at AP or STA and it will be delivered in aggregations of 1,2 ,3 ,4 or more frames. This is, as you said – throughput simulations. But in your graphs not input traffic of 32Mbps or 96 Mbps can delivered meaning that some frames are either a ) dropped or b) enqueued without a chance for transmission at AP side You confirmed that there is no AMSDU life time, so no frames are dropped because of that reason, so (a) is not an option SO, I rephrase my question from “why system fail to deliver input traffic with such low loads” to “what prevent system (AP in particular) from delivering traffic in DL ? Where the undelivered frames go”? [Yunbo] It is a good question. Let me try to explain the reason EMLSR fails to deliver all packets under 3Mbps traffic rate base on my understanding. We have limited simulation
time (1s is used), if the frames arrived at MAC at first 4ms can not be delivered within this cycle, some of them will be deferred to the second 4ms, and it is easy to understand that there will be more frames waiting for transmission in the second 4ms, so
more packets will be deferred to the 3rd 4ms. So for the packets that arrivals to the MAC in last multiple 4ms cycles can not be delivered in time when we terminate the simulation.
Follows this analysis, below results may happens when we extend the simulation time to infinity (or a very large number)
l
For extremely low traffic rate (e.g. 0.3Mbps), EMLSR can deliver all packets within each cycle, so EMLSR and NSTR have same throughput.
l
When traffic rate get higher (e.g. 1 Mbps), EMLSR can not deliver all packets within each cycle, but the tail (the number of following cycles that needed to deliver the
packets in this cycle) will not grows forever (because the deferred packet that transmitted in next cycle will be aggregated, no extra signaling control and PHY overhead is needed, the total time that needed to transmit an A-MPDU aggregates n+1 MPDUS is almost
the same as the time to transmit an A-MPDU aggregates n MPDUs), in that case for finite simulation time, EMLSR will be worse than NSTR, when we increase simulation time to infinity, the performance of EMLSR will approaches to NSTR.
l
When the traffic rate get higher more (maybe 10 or 30 Mbps?), EMLSR can not deliver all packets within each cycle, and the tail (the number of following cycles that needed
to deliver the packets in this cycle) will grows forever (because when the aggregation is larger and larger, it will limited by two factors: one is the maximum number of A-MPDUs, the other is maximum PPDU durations), in that case for the packets arrives in
the kth cycle will need to be delivered in next n_k cycles, the packets arrives in the (k+1)th cycles will need to be delivered in next n_(k+1) cycles, and n_(k+1) is larger than n_k. In that case, even when we increase simulation time to infinity, the performance
of EMLSR will always worse than NSTR. What is the behavior of a STA/STAs if case if they observe MuRTS frame from the AP that is not addressed to them? [Yunbo] no switch will happens.
Do you assume eMLSR STA completely switch all radio to one link where it see a transmission and because blind/not present on another link? [Yunbo] when eMLSR STA do either DL or UL transmission/reception, it switch all radio to one link, and no radio on another link, so it is blind on another link. And probably last point – I don’t think this has to be somehow connected with blindness. In you sims you have sufficient number of devices. So when some eMLSR schedule blindness timer, it can a) send RTS if it see medium
as IDLE and b) it will see at least one transmission within 5.4ms timer time simply because each STA has a packet for transmission every 4ms/12Ms for .03/3Mbps load, which mean there is always someone transmitting on any of the links within 1ms time interval.
[Yunbo] Agree with you. In dense scenario a STA in blindness can easy to re-sync with the medium due to the reception of other frames. We did it in the simulation follows the spec. Dmitry From: Liyunbo <liyunbo@xxxxxxxxxx>
Hi Dmitry, Thanks for your detailed analysis. Please find my response below in-line. Regards, Yunbo 发件人: Akhmetov, Dmitry [mailto:Dmitry.Akhmetov@xxxxxxxxx]
Hello Yunbo, Following Minyoung’ s questions/comments, I’d like to repeat my (and Sindhu’s) question regarding eMLSR not being able to deliver all offered traffic in case of 3Mbps (and even 1Mbps) case (on slide 7). Your explanation
was “it is because of huge overhead” associated with eMLSR mode of operation. I do not agree with that explanation. You said that traffic rate of 3Mbps is the input traffic at each MLD in both DL and UL direction, which mean every device has 3Mbps delivered to its peer device (STA has 3Mbps tpt be delivered to the AP and AP has 3 Mbps
delivered to each STA) Total load is 96Mbps = 3Mbps*(2 AP*8STAs*2 streams in DL auld UL) which is confirmed by total delivered tpt in NSTR case If you model your traffic as CBR, it mean a single frame arrive to the MAC every 4ms. In case of eMLSR, AP or STA need ~370us to deliver 1 (one) 1.5Kb packet in a single transaction including MuRTS + CTS + DATA + BA.
If you need to deliver 4 packets (aggregated) in one AMPDU – you will need a bit more time, about 400us.
So, just theoretically, if AP serve eMLSR devices in round robin fashion (i.e. one by one) on ONE link, AP will deliver all buffered traffic in DL direction within frame interarrival time. In your sims you have 2 APs , each serving 8 clients operating on 2 (TWO) links. So AP has a freedom of selecting different client for frame exchange, i.e. if it is sending or receiving data to/from eMLSR STA1 it can
always serve other eMLSR STA2 on another link, so this is not a bottleneck. You also indicated that you use MU-MIMO in both DL and UL meaning a single AP in a single transaction can serve 2 clients at a time on one link or potentially 4 client at a time on two links. With that in mind I simply see no chance for eMLSR (in fact for any other mode of operation not to deliver buffered stream with that tiny input data. I do not see how overhead play such significant role here.
[Yunbo] For 3Mbps traffic rate, single frame arrive to MAC every 4 ms. So within 4 ms, there will be 16 DL frames and 16 UL frames waiting for transmission. Assume 2 STAs are aggregated in each
MU-MIMO transmission and half of the UL transmissions are through UL MU-MIMO, there will be 8 DL transmission and 12 UL transmissions, totally 20 transmission. We got 2 links, so 10 transmissions in each link. Each transmission is 400us, so you can see the
traffic load is 400us *10/4ms = 100%. Considering the aggregation, the load will reduced somehow. But please remember that once there is 1 frame in the buffer of a MLD, this MLD will try to contend to do the transmission, it will not waiting for aggregation.
So you can see that it is so light load as you expected. When collision is considered, the load will be higher. Even more, if you take a look at 1Mbps load case you will see same problem, eMLSR does not deliver all buffered data. The packet arrival pattern (assuming CBR) is 1.5Kb packet every 12ms. This is huge. So with all possible
imperfections set to max values like switching delays (128us)/blindness recovery(5ms max)/Initial frame overhead (200us max) is simply impossible that buffered traffic of total 32Mbps cannot be delivered on time. [Yunbo] for 1Mbps, the arrived frames are separated among 12 ms, it is harder to aggregate different STAs in MU-MIMO. So most transmission will be SU transmission. Assuming all transmission are SU
transmission, there will be 32 transmission within 12 ms. There will be 16 transmissions on each link. So the traffic load will be 400us * 16/12ms =53.3%. The traffic load will be higher when collision is considered. I think that may be that’s the reason why
a very small portion of packets can not be successfully transmitted. You can see that when the traffic rate reduced to 0.3Mbps, all the packets are successfully transmitted. I see the only reason for not delivering that traffic – and you mentioned it on slides for Delay simulation - the MPDU lifetime. For delay sims it is set for 20ms. May be you use it somehow for throughput sims as well.
If so, well… it is a) strange to use it for throughput sims b) if it used and it is really 20ms…. I simply do not see how you can reach 20ms delay for a packet with such lightly loaded scenario. [Yunbo] there is no MPDU lifetime limitation in throughput simulation. Dmitry From: Minyoung Park <mpark.ieee@xxxxxxxxx>
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, Minyoung On Wed, Mar 23, 2022 at 9:48 AM Liyunbo <00001846a2e5e0c1-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
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 |