| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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
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]
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>
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 |