Hi Minyoung,
I think we understand each other very clear now. Please see my response inline in
purple.
regards
于健 Ross Yu
Huawei Technologies
发件人: Minyoung Park [mailto:mpark.ieee@xxxxxxxxx]
发送时间: 2020年6月18日
13:22
收件人: Yujian (Ross Yu) <ross.yujian@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] TGbe Teleconferences [06/17/2020 and 06/18/2020]: Agendas Posted
Hi Ross,
If what you are suggesting is switching between (1) single-radio/link (2x2 MIMO) and (3)STR MLD(1x1 each link), then you are agreeing to the concept of the proposed enhanced single-radio/link operation (2) because
(1)+(3) is effectively (2) with additional (non)STR capability. Please see below my responses as well. I think you are heading to what I'm trying to say our views are getting closer.
Hi Minyoung,
Let me ask some clarification questions. The simulations should compare
(1)+(3) and (2). This is the more interested and fair comparison.
[MP] Your suggested model (1)+(3) is effectively (2) with additional (non)STR capability. This is because in order to receive data on any available link, the non-AP MLD needs to operate as (3) and listens on two
links simultaneously with 1 RF chain on each link and then when it receives RTS on one link then it switches to (1) to receive 2ss data frame. This is the same operation of (2) enhanced single-radio/link. When operating in (3), however, the non-AP MLD can
use each link independently and this is because each link has its own 11be PHY and 11be MAC and this is the additional cost (1)+(3) is paying for the STR capability. But when operating as (3), its throughput is not better than (1) or (2) because for
(3) only 1ss is received on each link independently whereas (1) and (2) can receive 2ss on one link so no difference. Actually it could be worse because when OBSS load is mid to high, the chance of getting channel access on both links at the same is lower
than getting access on either link, so many times (3) will just receive 1ss data on one link unless it uses scheme like (2).
Do you agree that (1)+(3) is effectively (2)?
Ross: I agree with your understanding “(1)+(3) is effectively (2) with additional (non)STR capability”.
For (1)+(3) is effectively (2), it depends on the scenario and the goal of the transmission. ML can enable reliability with duplication in two links. And will work well if the two links are far enough. I understand the operation you said and I agree with its
benefit compared with only (1) or only (3) (but not 1+3). But I don’t think the necessity of defining a new type of MLD besides single-radio non-AP MLD and multi-radio non-AP MLD.
For the concept, the difference between semi 1+1 and full 1+1 is, for full 1+1, you have
a flexible choice to transmit 1+1 (w/o RTS/CTS exchange) or 2*2 (need RTS/CTS exchange). And similarly for the AP’s choice to transmit DL data.
[MP] I guess the full 1+1 means STR capability with 1 RF chain on each link. If this is correct, I agree that STR MLD with 1x1 on each link can transmit on both links simultaneously and also receive on both links simultaneously
but there is no throughput benefit operating in the simultaneous transmit mode with 1ss on each link or simultaneous receive mode with 1ss on each link and again for OBSS load mid-high, there will be less chance to transmit in the simultaneous mode
so it is better to operate as 2x2 on any available link. The flexibility comes because there are additional 11be PHY and 11be MAC blocks with associated complexity/cost. Do you agree on this point?
Ross: like I said in the last paragraph, it depends on the use case and scenario. And for the complexity/cost, our implementation team really don’t
think that’s a significant gap between semi 1+1 and full 1+1.
It is more like a mode change of a multi-radio MLD, rather than a different device type.
Also, regarding complexity and cost, the comparison should be between ((2)=(1)+(semi 1+1))
and ((1)+(3)). Equally the comparison is between semi 1+1 and full 1+1.
Semi 1+1: one 11be PHY + small non-HT PHY with limitation, one 11be MAC + small MAC with
limitation (CCA, RTS processing)
Full 1+1: one 11be PHY + one 11be PHY.
[MP] There seems to be an error here. Doesn't full 1+1 need any MAC? The full 1+1 is STR MLD with 1x1 on each link so it should have one 11be PHY and one 11be MAC to support one link and another 11be PHY and 11be
MAC for another link independently. So the comparison should be:
Semi 1+1: one 11be PHY + small non-HT PHY with limitation, one 11be MAC + small MAC with limitation (CCA, RTS processing)
Full 1+1: one 11be PHY + one 11be MAC, one 11be PHY + one 11be MAC.
and we see considerable delta between Semi 1+1 (i.e. listening to two links simultaneously with limitation) and Full 1+1 (STR capability on two links)
Ross: Agreed. Focused on PHY too much.
We can have more time to discuss and see if we can comprise.
regards
于健 Ross Yu
Huawei Technologies
发件人:
Minyoung Park [mailto:mpark.ieee@xxxxxxxxx]
发送时间: 2020年6月18日
0:17
收件人:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] TGbe Teleconferences [06/17/2020 and 06/18/2020]: Agendas Posted
Hi Ross,
RE: "I assume (3) and (1) are switchable.
It is similar as (2), which can work in 2by2 (1) or a semi 1+1"
To switch between (3) and (1), how does a receiver know when to switch from (3) to (1)? or (1) to (3)? For example, can AP transmit 2x2 data frames on any link
for (3)? Also, do you agree that there is no throughput performance benefit between operating as (1) for some time and (3) for another time for data exchange?
It sounds like you are agreeing to the concept of listening to two links simultaneously and STA using one of the two links that AP has access to for 2ss data
exchange (highlighted above), which is what the enhanced single-radio/link operation is about. Do you agree on this point?
For the complexity/cost, we do see considerable delta between (1) and (3).
Hi Minyoung,
Thanks for the detailed replies. I assume (3) and (1) are switchable. It is similar as (2), which can work in 2by2 (1) or a semi 1+1. It is not fair to think (3) can only work in full 1+1 mode. I think this is the different understanding.
Then the question is the cost/complexity gap between a semi and full 1+1. I double checked and the gap is small and not worth to have another mode.
--------------------------------------------------
regards
于健 Ross Yu
Sent from Great Huawei Mate 20X
主 题：Re: [STDS-802-11-TGBE] TGbe Teleconferences [06/17/2020 and 06/18/2020]: Agendas Posted
Please see below and also the last slide of 526r4. It explains the comparison between
(1)single-radio/link (2x2 MIMO), - total RF chain = 2, one 11be PHY, one 11be MAC
(2)enhanced single-radio/link (2x2), - total RF chain = 2, one 11be PHY+small non-HT PHY with limitation, one 11be MAC+small MAC with limitation (CCA, RTS processing)
(3)STR multi-radio (1x1 each link), - total RF chain = 2,
two 11be PHY, two 11be MAC
(4)STR multi-radio (2x2 each link). - total RF chain = 4,
two 11be PHY, two 11be MAC
Note: total number of links = 2 for (2), (3), and (4).
It looks like you are
mixing (3) and (4) when you do comparison with (2). It seems like you are comparing (2) and (4) when you say (2) has worse performance than (4). But when you say the enhanced single radio has the same cost as multi-radio, you are comparing (2) and (3).
Do you agree that this was the case? Could you please clarify how many RF chains you were assuming in your comparison in your email?
For STR multi-radio to perform better than single-radio/link(2x2), the STR multi-radio needs 2x2 MIMO on each link, which is (4) above, which is effectively doubling
the cost. For (3) with 1 RF chain on each link, the cost is not as big as (4), but since data transmission is done in one spatial stream, even though the STR multi-radio (1x1) operates on two links simultaneously, the performance is similar to (1) because
data is transmitted with one spatial stream on one link.
When comparing (2) enhanced single-radio/link (2x2) and (4) STR multi-radio (2x2 each link),
the cost of (4) is close to double of (2) and in return (4) performance better than (2) when OBSS load is low. However,
when the load increases, (2) and (4) performs similarly.
When comparing (2) enhanced single-radio/link (2x2) and (3) STR multi-radio (1x1 each link), the cost of (3) is still larger than (2) but not as big as (4).
However, the performance is now worse than (2) because (3) has a single RF chain on each link and can transmit only one spatial stream on a link. So although (3) is STR multi-radio and operates on two links simultaneously, performance doesn't increase
compared to (1) and is worse than (2).
Regarding your points on the mobile device support of multi-radio, since
11be needs to support not only mobile devices but also other types of devices (e.g. laptops), it would be not right to generalize multi-radio is already supported for all device types. For laptops, multi-radio is not common and 11be needs to support
such devices. Do you agree that 11be should support other device types such as laptops?
Hello Minyoung
Thanks for providing the following SP. It seems the enhanced single radio has the same
position as non-STR MLD based on Sindu’s analysis. First, non-STR MLD is already in the spec, and single radio device is widely supported now, we do not need any similar thing as them unless it has obvious gain, otherwise it will complicates the multi-link
operation. Second, enhanced single radio obviously performs worse than multi-radio, including non-STR. For example, about 30% throughput gain lost in your simulation (may need further evaluate it for more scenarios ). Third, enhanced single radio has almost
cost as Multi-radio. I double checked with our implementation guys, please refer to the following analysis
1.
enhanced single radio and Multi-radio have exact same RF and ABB,e,g., AGC. They both need two PLL (take two-radio for example)
2.
enhanced single radio and Multi-radio have almost same DBB, have the same number of DBB, the slight difference for enhanced single radio is that it has some DBB with limited function. However,
their cost are almost same.
Moreover, now we already have mobile device which supports multi-radio (dual band wifi),
like OPPO Reno 10x, OPPO R11, Vivo iQOO, realme X50 and so on. I do not find any motivation to downgrade the performance of 11be given
the almost similar cost.
By the way, I am confusing at you guys’ logic now, you guys propose to cut down everything
to catch TGbe timeline, like AP coordination, even for simple AP coordination. Why not cut down enhanced single radio? Compared with AP coordination and HARQ, its value is much more low.
Just for fun, do not think enhanced single radio is like wake up radio?
Best wishes,
Ming Gan
发件人:
Minyoung Park [mailto:mpark.ieee@xxxxxxxxx]
发送时间: 2020年6月17日
12:09
收件人:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] TGbe Teleconferences [06/17/2020 and 06/18/2020]: Agendas Posted
Hi Alfred, Jeongki,
Could you please add the following SP in 11-20/562r4 to the MAC call on June 18th under Deferred SPs from Previous Topics? I had offline discussions with no voters
and resolved most of their concerns. I've also added more explanations at the end of the presentation how the proposed approach fills the gap between a single-radio/link 2x2 MIMO and STR MLD (2x2 per link) in terms of complexity and performance.
SP2: Do you support the concept of the multi-link operation for an enhanced single-link/radio (TBD) non-AP MLD that is defined as follows for R1?
-
An MLD that can: 1) transmit or receive data/management frames to another MLD on one link, and 2) listening on one or more links.
-
The “listening” operation includes CCA as well as receiving initial control messages (e.g., RTS/MU-RTS)
-
Link switch delay may be indicated by the non-AP MLD
I uploaded an updated version of the agendas, which contains the agenda for the next two conference calls:
- June 17 (Wednesday) – MAC 10:00-13:00 ET
- June 18 (Thursday) – MAC/PHY 19:00-22:00 ET
The agendas can be found here:
The dial in details can be found in the IEEE 802.11 calendar in their respective entries. The calendar can be access from this
webpage
Please note the following:
* For MAC ad-hoc conf calls:
For the Thursday Conf Call we will continue with technical submissions from where we left on the Wednesday Conf Call. As usual they will be preceded by deferred SPs from previous topics, and by deferred SPs from current topic.
An update will be sent after Wednesday's MAC ad-hoc call which includes the updated agenda for Thursday's MAC ad-hoc call.
* For PHY ad-hoc conf calls:
Please let me know if you have any submissions to be added to the PHY agenda. As of now there are no submissions scheduled for the Thursday PHY conf call (please see guideline below prepared based on feedback from PHY ad-hoc group).
PS: Guidelines for PHY conf calls:
-
Every time the agenda is sent the TG chair will ask if there are any submissions requests to be added to the PHY submissions queue. Requests can be regarding new submissions or regarding submissions with deferred SPs.
-
Requests may explicitly indicate if the requestor prefers to discuss his/her submission at a particular PHY conf call. If there is no such explicit indication then the submission will be added by default to the PHY submissions queue and will
be scheduled for presentation in a subsequent PHY conference call during which there are at least 3 submissions available for discussion.
-
A scheduled PHY conference call will be cancelled if the planned PHY agenda for that particular conference call does not have queued at least 3 presentations or at least one presentation with an explicit request. The cancellation notice in
this case will be sent at least 24 hours in advance.
Please let me know if you have any questions and/or
suggestions.
Best Regards,
--
Qualcomm Technologies Inc.
Office #: +1 858 658 5302
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
|