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

Re: [STDS-802-11-TGBE] 答复: Discussion on DCN680r1 Operating Bandwidth Indication for EHT BSS



Hi Rui, Guogang, Ross, Bin, and Younghoon,

 

 

Thanks for discussion.

 

I am kind of agree with Rui.

First of all, it is not clear when 80+80/160+160 will be used on top of MLO.

As far as I know, end PPDU alignment is already agreed in MLO which is aiming for non-STR MLD.

MAC

 

 

 

 

 

 

MLO-Multi-link channel access: End PPDU Alignment

Yongho Seok

Yunbo Li,

Insun Jang,

Matthew Fischer, Duncan Ho Minyoung Park, Liwen Chu,

Dibakar Das, Jarkko Kneckt, Chunyu Hu, Tomo Adachi,  Jeongki Kim, NEZOU Patrice, Sharan Naribole, Yonggang Fang, Zhou Lan, Akhmetov Dmitry, PEYUSH Agarwal, Liuming Lu, Ryuichi Hirata, Sanghyun Kim, Xin Zuo, Sebastian Max, Laurent Cariou, Jonghun Han, Youhan Kim, Chunyu Hu, John Yi, Hanseul Hong

Basics in R1 (see note)

 

20/1271r0, uploaded on August 24, 2020

20/1271r1, uploaded on August 26, 2020

Motion 111, #SP0611-31

Motion 122, #SP152

Motion 122, #SP153

Motion 122, #SP154

Motion 122, #SP159

Motion 122, #SP168

Also, there is ongoing discussion on start of PPDU.

MAC

MLO-Multi-link channel access: Synch Start of PPDU

Duncan Ho

Yongho Seok, Yunbo Li, Insun Jang, Matthew Fischer, Akhmetov Dmitry, Minyoung Park, Liwen Chu,

Dibakar Das, Jarkko Kneckt, Chunyu Hu, Tomo Adachi, Jeongki Kim, NEZOU Patrice, Sharan Naribole, Yonggang Fang, Zhou Lan, Akhmetov Dmitry,  PEYUSH Agarwal, Liuming Lu, Ryuichi Hirata Sanghyun Kim,

Xin Zuo, Sebastian Max, Laurent Cariou, Jonghun Han, Youhan Kim, John Yi, Hanseul Hong

ON HOLD

 

No motion

If both agreed, then having extra 80+80/160+160 seems duplicated mode of operation.

 

Second, as Rui mentioned, 80+80 is not used much (actually I didn’t see one yet).

If this is not used, but defined, then non-AP STA may implement it without using it.

If a certain feature is not useful and used, then it will be better not to define in new generation WiFi.

 

Several PDTs are depending on this decision.

Obviously we don’t want to write some text for some mode, and then remove it soon.

So, it is better to be decided whether we will support it or not.

Is it possible to run following SP one more time during the PHY call tomorrow?

Do you agree that 11be does NOT define PPDU with non-contiguous signal bandwidth?

·        Non-contiguous signal bandwidth includes 80+80MHz, 160+80MHz or 160+160MHz.

·        This does not include punctured modes within 160, 240 or 320MHz BW.

·        160+80 MHz PPDU is TBD within 320MHz.

 

Best regards,

Wook Bong Lee

 

 

From: huangguogang [mailto:huangguogang1@xxxxxxxxxx]
Sent: Wednesday, August 26, 2020 1:53 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE]
: Discussion on DCN680r1 Operating Bandwidth Indication for EHT BSS

 

Hi Rui,

 

“The non-contiguous PHY modes have been defined in two generations, and chip vendors and market have made the choice not to use the modes. ” This doesn’t mean that the non-contiguous PHY modes still will not be used in 11be. I agree that currently seldom STA products support the non-contiguous PHY. In my understanding, the main reason is to reduce the cost of STA side. But with the advent of multi-radio non-AP MLD device, I think that the non-contiguous PHY mode will be used in some scenario.

 

In your contribution, you only consider the comparison with the STR MLO. Maybe the comparison with the non-STR MLO is also needed.

 

 

Regards

Guogang Huang

 

发件人: Rui Cao [mailto:rui.cao_2@xxxxxxx]
发送时间: 2020826 9:19
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: Discussion on DCN680r1 Operating Bandwidth Indication for EHT BSS

 

Hi Guogang,

 

Agree that 80+80/160+160 is already in the SFD. But the non-contiguous modes was added following 11ac/ax style without thorough justification.

We have some analysis in our contribution that the non-contiguous modes do not provide throughput benefits.

 

So it’s a better way to leave the choice right to chip vendors.

 

The non-contiguous PHY modes have been defined in two generations, and chip vendors and market have made the choice not to use the modes.

This is the main reason that we propose not to define non-contiguous PHY modes in 11be to avoid unnecessary complexity in spec.

 

MLO is a new approach to enable non-contiguous operation. 11be may define different schemes for chip vendors/market to choose. But for proven unused modes, we don’t need to carry them into future.  

 

Thanks,

Rui

 

From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: Tuesday, August 25, 2020 12:50 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE]
答复: Discussion on DCN680r1 Operating Bandwidth Indication for EHT BSS

 

Hi Young Hoon and Rui,

 

Thanks for the comment. The baseline is that the 80+80/160+160 is already in the SFD. I just follow the current SFD.

 

For the non-contiguous PHY transmission (80+80/160+160), I still want to keep it. There are the following reasons;

 

          In some regions, there exists only non-contiguous channels, rather than the contiguous channels.

          Comparing 80+80/160+160 with non-STR MLO, the channel access is much simpler. Based on the off-line discussion, some companies don’t like the non-STR MLO. So it’s a better way to leave the choice right to chip vendors.

          Since some info needs to be timely shared cross links in order to realize the PPDU alignment, the implement complexity of non-STR MLO is much higher than the one of non-contiguous PHY transmission.  

 

Hence, from implementation point of view, I want to support either way, depending on the scenario.

 

Regards

Guogang Huang

Huawei Technologies Co.,Ltd.

 

发件人: huangguogang
发送时间: 2020821 9:31
收件人: 'Young Hoon Kwon' <younghoon.kwon@xxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: 答复: Discussion on DCN680r1 Operating Bandwidth Indication for EHT BSS

 

Hi Young Hoon,

 

I know this situation. The main reason mentioned in DCN 1100  is that few 80+80 operating STA on the market. But I think if the device is the MLD device, this mode can be used.

 

I suggest to represent the contribution 1100r0 and run it again in the next joint teleconference call. After that, I can run my SPs.

 

How about it?

 

Thanks,

Guogang Huang

 

 

发件人: Young Hoon Kwon [mailto:younghoon.kwon@xxxxxxx]
发送时间: 2020821 2:37
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: Discussion on DCN680r1 Operating Bandwidth Indication for EHT BSS

 

Hi Guogang,

 

Thanks for bringing up this issue to the table.

Actually I also have a similar contribution (684r0) that was presented last time and my own SP is in line with your SPs.

However, based on the off-line discussion, quite many members want me to hold off my own SP because it depends on PHY’s decision on allowed PPDU bandwidth.

And, even though some SPs in PHY (e.g., SP1 of 1100r0) does not get enough support to not allow 80+80MHz and/or 160+160MHz PPDU, it looks there’s no clear decision made on this issue in PHY side yet.

Under this situation, I think we better not be in a hurry in deciding the Channel Width and CCFS field definition until the PHY discussion on this topic is cleared.

 

How do you think?

 

Thanks,

Young Hoon

 

From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: Thursday, August 20, 2020 1:18 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Discussion on DCN680r1 Operating Bandwidth Indication for EHT BSS

 

Hi all,

 

I have upload a new version of DCN680. I prepare to run the following two straw polls in the next week. If you have any concern or suggestion, please let me know.  

 

    SP2. Do you support to define EHT Operation element with two CCFS subfields (EHT_CCFS0/EHT_CCFS1) to indicate channel configuration for EHT BSS?

 

    SP 3. Do you support to use 3 bits of Channel Width field in EHT operation element to indicate the channel width for EHT BSS as following

  0: 20

  1: 40

  2: 80

  3: 160/80+80

  4: 320/160+160

  5~7: reserved

 

 

Regards

Guogang Huang

Huawei Technologies Co.,Ltd.

 


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