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

[STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答���: [STDS-802-11-TGBE] Request for further discussion on SP198 non-primary transmission



Hello Sindhu,

 

I also did homework with our colleagues. Based on ETSI regulation, there are two options such that NRU has two types for multi-channel access, one is type A and the other is type B. but the device can just choose one. Our NRU colleagues told me both type A and type B have their own advantages and drawbacks, it is difficult to say which one is better.  As u said, if going to opt 1, then you can not have primary channel and can not use PIFS access (25 us), you lose opportunities to construct the large bandwidth. However, based on your contribution, there is a primary channel. If going to opt 2, the primary channel can not be changed in 1 second. Please tell me how you get the gain under this condition- perform backoff on the secondary channel.

 

Best wishes,

Ming Gan

 

发件人: Sindhu Verma [mailto:000011381223f2e2-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 2020917 20:32
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Request for further discussion on SP198 non-primary transmission

 

Hi Ming and Guaogang,

 

To add something to what Matt/Vinko/Kaiying already mentioned:

 

  • Regulatory aspect:
    • The ETSI regulations already allow independent access to all the 20 MHz channels that are a part of a multicarrier operation, provided there is full EDCA (truncated exponential backoff) on each of them. Such an access scheme is the first option (Option 1) in the ETSI harmonised standard for 5GHz (EN 301 893). In fact, this option is considered fairer than the second option (Option 2) which allows the current 802.11 channel access scheme (where there is full EDCA is done on only one channel and PIFS on other bonded channels). LAA and NR-U make use of the first option of independent access on all channels as the default scheme, and are allowed to use the 802.11-like scheme only in case of 802.11-like channel bonding constraints. We are only proposing to support  both the options  in 802.11be as well.
  • Competitive aspect:
    • 802.11be is expected to compete with LAA/NR-U, which in some forums are being touted as 5G(IMT-2020)-compliant technologies that are superior to 802.11. With 11be, we support all the state of the art features in LTE/NR such as wide bandwidths, high MCS, multi-link, punctured transmissions etc. However, it would undermine the real world performance of 11be if its efficiency is determined solely by the availability of a single 20MHz channel. For example, consider a 320 MHz bandwidth, where 11be depends on the availability of a single 20MHz channel to make any transmission and where LAA/NR-U can combine and use any subset of available channels.
  • Fairness to legacy devices:
    • The current SP clearly states that the secondary-only channel usage is dependent on the primary channel being busy and the proposals so far require the usage to be restricted to the duration of the primary channel transmission. In that case, there is no impact on legacy devices if they have the same primary as the primary channel of the 11be device.
    • If the primary channel of a legacy device is a secondary channel of the 11be device, the 11be device competes with the legacy device just like any other legacy device by using full EDCA.  
    • Importantly, if by making efficient use of wide bandwidth, the 11be device is able to drain its buffer faster, it helps legacy devices in the network. For example, if the 11be device sends a lot of its traffic using secondary-only transmissions, it will use the primary less and which will become more available for legacy devices.
    • For wideband operations up to 320 MHz, no legacy devices in an 11be network can utilize the full bandwidth. Hence, it is easily possible to partition the bandwidth into legacy and 11be operation.
    • A lot of other mechanisms and parameters like ED/PD thresholds are still open for discussion and can be tuned to ensure additional fairness. 
    • Hence, it is unfair to restrict 802.11be to inefficient wideband operation for the argument of fairness to legacy devices. 
  • Simulations/Evaluations to show benefit:
    • The benefits of independent access to the channels of a wideband operation are intuitive.
    • In 802.11ax, preamble puncturing was incorporated realizing the limitations of depending on certain channels to be available for transmitting on other channels. However, 11ax retrained the dependence on the primary 20MHz channel being available
    • By corollary, if we remove the dependence on the availability of the primary 20MHz as well, the operation can only be more efficient
    • A simplified calculation to show the advantage of the proposal: If there are 4 channels each being available with a probability of 0.5:
      • For 11ax: 
        • Probability of 80MHz transmission = 0.0625
        • Probability of 60MHz transmission = 0.1875
        • Probability of 40MHz transmission = 0.0625
        • Probability of 20MHz transmission = 0.1875
        • Probability of no transmission = 0.5
        • Average transmission bandwidth =22.5MHz
      • For 11be with this feature:
        • Probability of 80MHz transmission = 0.0625
        • Probability of 60MHz transmission = 0.25
        • Probability of 40MHz transmission = 0.375
        • Probability of 20MHz transmission = 0.25
        • Probability of no transmission = 0.0625
        • Average transmission bandwidth = 40MHz
      • In the above example, if 320MHz is used instead of 80MHz, the gains due to the feature will be even higher.

 

Many of the above points have been already mentioned in our contribution 20/0363r3, during the meeting Q&A and in email discussions. It would have also helped to receive this request for discussion a bit earlier. We could then have discussed and resolved these and reached a conclusion before the motion today.

 

Regards,

Sindhu

 

 

From: Matthew Fischer [mailto:00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: Thursday, September 17, 2020 9:25 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] Request for further discussion on SP198 non-primary transmission

 


Ganming,

 

Please see embedded comments:

 

On Wed, Sep 16, 2020 at 7:25 PM Ganming (Ming) <ming.gan@xxxxxxxxxx> wrote:

Hello Vinko and Matt,

 

Thanks for providing your opinions here. I think running this motion is a little bit early. Non-primary channel access topic is not new, we discussed this again and again. Large BW could not be the reason, we introduced the 160MHz large bandwidth in 802.11ac, almost 10 years ago. This may not gain much as we expect. Please refer to the following points

 

1.       Complicate scenarios on unlicensed band. Not only WiFI devices operate on this band, that means it is difficult to get primary channel busy time. So if the AP/STA goes to do channel access on the  secondary channel in this case, the STA parking the primary channel could be out of the service, this is dangerous. Moreover, even if primary channel busy results from WiFi signal, The AP/STA may also miss the preamble of WiFI PPDU or NAV could also be updated during the period when the AP/STA provides the service on the secondary channel.

All of the proposals discussed thusfar have indicated that the secondary channel access should be limited to the duration of the PPDU or TXOP on the primary channel.

If the busy is caused by a non-802.11 signal of which the duration is unknown, then the secondary access would not occur.

If any 802.11 signal has caused that busy condition, then there would be no other 802.11 signal to receive while the first signal is present.

[There is no such thing as preemption in 802.11]

2.       When the AP/STA intends to provide the service on the secondary channel, however, it does not know the status of that channel. If doing channel access immediately, it will break the balance of that channel and cause a series of problems. Otherwise, “waiting” results in spectrum resource waste.

Again, none of the proposals that have been discussed would provide immediate access to the secondary channel.

Channel state assessment and would include randomization, as without it, collisions will be generated among the competitors for the unused resource. 

3.       We have PPDU preamble Puncture and Multi-link techniques now, both of these could alleviate or address the non-efficiency issue. Why not need another complicate or immature technique.

These existing techniques all rely on primary channel access. If the primary channel is busy, these techniques do nothing to utilize available bandwidth.

 

Competing technologies in the unlicensed bands have protocol definitions and implementations that allow parallel multi-channel access to be able to find and utilize any and all available channels.

If we do not adopt similar techniques, we will not compete well for the use of the resources and our technology will be replaced by something that is better able to take advantage of the open public resource.

 

4.       The solutions now are not clear, no full picture, no simulation evaluation. It is reasonable to have further discussion IMHO

This is an R2 feature, allowing plenty of time to ensure that the details are well-vetted.

 

Matthew Fischer

 

 

….

 

Best wishes

Ming Gan

 

 

发件人: Vinko Erceg [mailto:00000c44f70266db-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 2020917 8:36
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Request for further discussion on SP198 non-primary transmission

 

I would also like to add that 20+ year old WLAN channel access assuming primary being idle is very inefficient mechanism, especially for wide BWs such 80MHz, 160Mhz and 320MHz. Since actual mechanisms are TBD, certainly can be made to fit within regulatory frameworks, LTE (NR-U) has mechanisms to exploit this already in an efficient way. Personally, I think that there is time for change, we should be able to yield significant gains. And yes, any new amendment is better than the old one - wider BW, higher modulation, lower latency, etc. … then why not include also more efficient channel access?

 

Thanks and Regards,


Vinko..

 

 

From: Matthew Fischer [mailto:00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, September 16, 2020 5:14 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Request for further discussion on SP198 non-primary transmission

 


Guogang,

 

Here are some responses to your specific questions:

 

1. the proposal provides an optional behavior and the performance depends on the available unused bandwidth, so it is very scenario dependent, but in any case, whenever it is used, it is taking advantage of BW that is otherwise unused, so it would be a net gain - whether that gain is worth the addition of the mechanism is an individualized tradeoff decision to be made by implementers, but we view the extra effort for implementation as not far from what is already being done on other channels, and again, if you do not accept the tradeoff, you can opt out by not implementing the option

 

2. provided that the access rules incorporate some random access, it should be within regulations

 

3. STA that are members of the BSS and that do not support the transmission or reception on secondary channels should not be affected if they are sharing the primary channel, as those devices would be shut out of access anyway - i.e. the secondary channel access only occurs when the primary is busy and some secondary channels are available - any STA that is legacy and therefore does not participate in the secondary channel access will be completely unaffected because they are waiting for the end of the busy condition on the primary channel

STAs that are OBSS and that do not support the transmission or reception on secondary channels that are not sharing the primary channel might see more competitive pressure, but this is not much different than what they already experience from full BW transmissions from the same in-BSS - i.e. this proposal simply means that more of the transmissions from my competing BSS will become full BW, but my BSS has the right to access the full BW already - this mechanism simply increases the number of TXOPs for which I exercise my full BW rights

 

 

Matthew Fischer

Nice Guy

Broadcom Inc.

+1 408 543 3370 office

 

 

On Wed, Sep 16, 2020 at 7:58 AM huangguogang <huangguogang1@xxxxxxxxxx> wrote:

Hi Alfred and sndhu,

 

I want further discussion on SP198 non-primary transmission. Because some issues need to be clarified before running the motion, e.g.

 

l  This is a big change for the WLAN system, but hasn't see some performance evaluations. We don't know how much gain we can get, and what's the affect for legacy system;

l  We need to evaluate whether it violate the regulation. It seems the proposed solution is a new architecture that not existed in current EU regulations.

l  Fairness issue to legacy STA or EHT STA that not support non-primary channel transmission.

 

Sndhu, could you please defer this motion?  We can do more offline discussion on it.

 

 

Regards

Guogang Huang

 


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


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