| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Xiangxin,
While the aspects that you have mentioned have been previously covered in the NPCA presentations, for example in 11-23/2023r1 and 11-23/1288r0, I would like to summarize some responses here inline below your comments::
Xiangxin>>From my point of view, the BSS STAs are at different locations in general and with different impacts by the OBSS PPDU. Some of them will switch to the NPC while others won’t. The AP and STAs don’t know whether the peer switch to NPC or not. So it is a complex mechanism and has to deal with many exceptions.
There are some straightforward solutions to this problem. With multiple clients, enforcement of triggered UL only (i.e. not allowing untriggered UL) is an obvious method. Untriggered UL is similarly not applicable for other features like UL MU-MIMO, SST as well as for the proposed DSO feature. Further, making any transmissions commence with (MU-)RTS/CTS further serve to limit any impact of loss of synchronization
Xiangxin>>Besides, I also doubt how many chances there will be to access NPC in practice, given that frequency resources are used out in dense deployments. Even though the AP and STAs do exchange frames on NPC, the duration of the frame exchange on the NPC is very limited.
In 802.11, when we say that a network is congested, it is meant that the primary 20MHz is mostly occupied; it is almost never that all secondary/non-primary resources are always occupied too. All kinds of devices exist with bandwidths varying from 20MHz to 320MHz even for 11be/11bn. Every time lower bandwidth transmissions are initiated, there is the possibility of utilizing non-primary channels. Below is a detailed discussion on such scenarios
Configurations with OBSS bandwidth narrower than the NPCA BSS bandwidth will be common, as 11ax BSSs have a max bandwidth of 160 MHz, and most 11ac BSSs are 80 MHz or less, while an 11bn NPCA BSS can have a max bandwidth of 320 MHz.
In many planned deployments, the BSSs are configured with much narrower bandwidth as a consideration for channel planning. For example:
The BSS bandwidths in the recently concluded IEEE 802.11 F2F meeting in Denver (both the IEEE802 and Hyatt hotel BSSs) were all 40 MHz.
Many office networks have 40 MHz BSSs bandwidths too.
NPCA + DSO will allow the 11bn BSSs in such deployments to be of wider bandwidth
Additionally, the actual transmission/occupied bandwidths are frequently lower than the max BSS bandwidth, due to:
Coverage-limited or power-limited clients.
For coverage limited cases, transmissions commonly use lower bandwidths to increase PSD.
Limited data rate requirements
Clients that support narrower max bandwidth than the BSS bandwidth. For example:
To my knowledge, even for 11ax, there are more than a billion clients that support a max bandwidth of 80 MHz. When any of those are engaged in single user DL/UL transmissions, the bandwidth occupied would be 80 MHz or less, irrespective of the actual BSS bandwidth.
11ax 20 MHz STAs that only use the primary 20 MHz.
Power save schemes being proposed for 11bn, will make it possible for wider bandwidth clients to listen and receive on bandwidths as low as 20 MHz.
OBSS DL/UL transmissions being narrow band due to sensing some of the secondary channels as busy.
Transmissions commonly use only a part of the bandwidth that a client or AP supports, due to sensing some of the secondary channels as busy while the primary channel is idle. This is the principle of dynamic bandwidth negotiation via RTS-CTS as well. An NPCA BSS, if it is far enough from hearing range of such interference, can use those secondary channels.
Presence of other technologies
The unlicensed spectrum allows other technologies to operate which may not always use 320 MHz.
There are also in-device coexistence considerations where a Wi-Fi device decides to temporarily pause Tx/Rx on a bandwidth that includes its primary channel. NPCA would make it possible for such a device to use any spare bandwidth, if there is any part of the secondary channel bandwidth that is idle, even when a section of the bandwidth that includes the primary channel is busy.
Xiangxin>>Overall, I think the idea is gain limited but very complex.
While I agree that NPCA (like any other potent enhancement) adds to complexity, I disagree that gains are limited. From intuition as well as evaluations, it is clear that NPCA has a lot of potential. It is a long-standing limitation of 802.11 to depend only on the availability of the primary 20MHz channel which is not present in any other unlicensed spectrum technology. This was ok when the operating bandwidths were narrower, but increasingly inefficient and wasteful with wider operating bandwidths. The longer we take to solve the limitation, the larger the challenge would be in handling the growing pool of 802.11 devices with this limitation.
Regards,
Sindhu
Hi Minyoung,
From my point of view, the BSS STAs are at different locations in general and with different impacts by the OBSS PPDU. Some of them will switch to the NPC while others won’t. The AP and STAs don’t know whether the peer switch to NPC or not. So it is a complex mechanism and has to deal with many exceptions.
Besides, I also doubt how many chances there will be to access NPC in practice, given that frequency resources are used out in dense deployments. Even though the AP and STAs do exchange frames on NPC, the duration of the frame exchange on the NPC is very limited.
Overall, I think the idea is gain limited but very complex.
BR,
Xiangxin Gu
Spreadtrum
From: Leonardo Lanante <llanante@xxxxxxxxxx>
Sent: Tuesday, April 2, 2024 5:10 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] NPCA SP feedback
Hi Minyoung,
We think it’s too early to dismiss STAs that are capable of decoding secondary channel NAV information at this stage of the task group. STAs can also obtain NAV information quickly from the PHY header without decoding an actual frame and we may see implementations that leverage this capability for NPCA. We believe it will be better for STAs to be aware that these implementations may exist so we prefer to remove the first bullet or make it TBD for now.
Thanks,
Leonardo
From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Thursday, March 14, 2024 6:18 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] NPCA SP feedback
You don't often get email from mpark.ieee@xxxxxxxxx. Learn why this is important
Hi all,
We ran the following SP in TGbn and the result was 99Y,42N,26A. Since the SP doesn't record the votes, I'm sending this email asking members who voted 'No' to please reach out to me so that we can resolve your concerns.
SP on NPCA:
Do you support to define in 11bn a mode of operation that enables a STA to access the secondary channel while the primary channel is known to be busy due to OBSS traffic or other TBD conditions?– The mode of operation shall not assume that the STA is capable to detect or decode a frame and obtain NAV information of the secondary channel concurrently with the primary channel.
– A BSS shall only have a single NPCA primary channel (name TBD) on which the STA contends while the primary channel of the BSS is known to be busy due to OBSS traffic or other TBD conditions.
Note: Discussed in several sessions and several submissions discuss similar concept, ref: 11-23/2005r1, 11-23/2023r1, 11-24/70r1, 11-24/458r0, 11-24/486r0, 11-24/538r0, 11-23/1935r1, 11-23/1913r2, 11-23/1911r0
Regards,
Minyoung
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature