Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] TGbe Teleconferences [06/17/2020 and 06/18/2020]: Agendas Posted

Hello Ming,

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?

Thanks,
Minyoung



On Wed, Jun 17, 2020 at 1:30 AM Ganming (Ming) <ming.gan@xxxxxxxxxx> wrote:

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

 

Thanks,

Minyoung

 

 

On Tue, Jun 16, 2020 at 9:59 AM Alfred Asterjadhi <asterjadhi@xxxxxxxxx> wrote:

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,

 

Alfred

 

--

Alfred Asterjadhi, PhD

IEEE802.11 TGbe Chair,

Qualcomm Technologies Inc.

Cell #:    +1 858 263 9445

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