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

Re: [STDS-802-11-TGBN] DSO PDT and CR doc 11-25/1164



Hi Gaurav,


There have been multiple emails sent over the reflector by me and others answering the exact points that you have raised in your email.


To reiterate, 20MHz/40MHz enterprise deployments do not require DSO support of 20MHz/40MHz non-APs. This is because all typical non-APs support a bandwidth of 80MHz and higher, irrespective of the bandwidth of deployment. Also, given DPS, there is no incentive for them to artificially downgrade bandwidth. For such non-APs, DPS and DL OFDMA suffice and DSO is not needed.

There are also no 40MHz non-APs. 


So, 20MHz-only non-APs (i.e. ones that can support a max bandwidth of 20MHz) are the only 20MHz devices that can be considered in DSO. There is active ongoing discussion to support such 20MHz-only non-APs to the extent technically feasible at the AP. As you can see this is also covered in the DSO SPs that have been circulated by Morteza.


Hi Rakesh,


I am somewhat surprised reading your email more than 2 months after I sent a comprehensive discussion regarding the supportable configuration for 20MHz DSO. This compromise configuration was suggested by some members keeping in mind implementability and gains. Had you expressed your disagreements to this earlier, we would have had more time to resolve and make progress.


More responses inline:


>>We would like to better understand the rationale behind the following restriction in the current draft:
“For a 20 MHz-only non-AP STA, only the secondary 20 MHz of a 40 MHz PPDU (in a 40 MHz, 80 MHz, 160 MHz, or 320 MHz BSS) shall be a DSO subband”.
The above text significantly limits the flexibility of DSO for 20 MHz STAs — a device category particularly relevant to the fast-growing IoT market.


As with all features, the supported configurations need to achieve a balance between flexibility and complexity. Flexibility is usually desirable to enhance performance . However, in this particular case, it is not clear that more flexibility to schedule the 20MHz non-APs with DSO would lead to better performance. Notwithstanding, while the need or instance of scheduling 20MHz in a wider-than-40MHz bandwidth can be extremely rare, based on your arguments regarding IoT use cases, we can still envision specialized scenarios where the operating bandwidth is 40MHz and with only the IoT 20MHz-only clients. To extrapolate this to a wider bandwidth and higher throughput scenario is not a desirable flexibility in terms of the complexity required to realize such configurations gainfully or even in terms of theoretical gains possible.


 
>>For comparison, 80 MHz STA is provided with all the DSO subband possibilities that could exist, i.e.
Similarly, a 20 MHz STA could logically support multiple viable DSO subband options across different BSS bandwidths: 3 subband options in a 80 MHz BSS, 7 subband options in a 160 MHz BSS, 15 subband options in a 320 MHz BSS.

While we are clearly not advocating support for all the aforementioned listed options, limiting it down to just one seems unnecessarily restrictive.
 
80MHz non-APs are not comparable to 20MHz-only non-APs which have existed since the inception of OFDM WiFi. In contrast with the low throughput requirements and capabilities of IoT devices, 80MHz non-APs can deliver throughputs in the order of Gbps of throughput along with MLO (Multilink too is not relevant for IoT devices). 80MHz non-APs would also implement NPCA because of which there can be resource constraints where it may be optimal for the non-AP to have a DSO subband option in the 160S. There are elaborate negotiations and handshakes being considered for this kind of flexibility in DSO subband assignment to 80MHz non-APs. Are you also considering NPCA for IoT devices? Have you considered the resource constraints because of which a non-AP may pick the 20S as its preferred DSO subband by default?


Even then, based on your insistence, many have compromised to consider 20MHz non-APs in their DSO design. But 20MHz DSO cannot be unconstrained or even as flexible as 80MHz because 20in80 or 20in160 or 20in320 DSO with 1 switching position cannot be realized in case of paucity of 80MHz or 160MHz non-APs to occupy the whole bandwidth. And once these much wider bandwidth non-APs are present, the motivation to perform DSO with 20MHz clients within such wide bandwidth reduces.




>>May we invite you consider our proposal of allowing more options for 20 MHz STAs — consistent with what's allowed for 80 MHz STAs. For example
 
While the above text calls out “Lower 20 MHz”, we are open to the possibility that any one 20 MHz subband of a 80 MHz band can be considered. The text corresponding to what a 160 MHz or a 320 MHZ AP can assign, will be derived accordingly.


Again, there is no comparison between the use cases of 80MHz DSO and the IoT use case you are qualifying your 20MHz DSO request with. Also, you have to consider the complexities of negotiation and scheduling of the various 20MHz DSO subband possibilities you mention above. Even for 80MHz case, per the current broad consensus, the AP is free to announce just one DSO subband. Analogically, in the 20MHz case, the AP would be free to announce 20S as the only DSO subband. 
 
>>Our aim is to enable meaningful DSO operation for 20 MHz STAs. Given that DSO is meant to improve channel utilization, a fallback to only the immediate adjacent 20 MHz channel (which is often similarly impacted) may offer little benefit in field deployments.


The gains from assignment of other than 20S as the DSO subband to a 20MHz-only non-AP or the gains of 20MHz DSO in general are not clear to many. However, the complexity of negotiation and scheduling in case of 20MHz DSO is a matter of unequivocal concern. In order to make progress, there is now willingness to implement 20in40 DSO and use it in the field. I urge you to acknowledge this change in position made by others to address your concerns and allow the acceptance of the configurations currently outlined in Morteza’s SP.
 

Regards,
Sindhu




On Mon, Jul 28, 2025, 8:39 PM Sai Nandagopalan <000048fda3cbd438-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Morteza

It is important that we discuss all the points raised by Rakesh on DSO in the floor.  If you want to keep it private that is also ok. 

With Best Regards
Sai

From: Rakesh Taori <Rakesh.Taori@xxxxxxxxxxxx>
Sent: Monday, July 28, 2025 3:37 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] DSO PDT and CR doc 11-25/1164
 
CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.

Dear Morteza,

 

Thank you for preparing the PDT/CR doc for DSO (11-25/1164). I truly appreciate the effort you've put into advancing this important topic..

 

We would like to better understand the rationale behind the following restriction in the current draft:

“For a 20 MHz-only non-AP STA, only the secondary 20 MHz of a 40 MHz PPDU (in a 40 MHz, 80 MHz, 160 MHz, or 320 MHz BSS) shall be a DSO subband”.

The above text significantly limits the flexibility of DSO for 20 MHz STAs — a device category particularly relevant to the fast-growing IoT market.

 

For comparison, 80 MHz STA is provided with all the DSO subband possibilities that could exist, i.e.

  • Secondary 80 in case of 160 MHz BSS, and
  • 3 options in case of 320 MHz BSS, of which one will be chosen,

 

Similarly, a 20 MHz STA could logically support multiple viable DSO subband options across different BSS bandwidths: 3 subband options in a 80 MHz  BSS, 7 subband options in a 160 MHz BSS, 15 subband options in a 320 MHz BSS. While we are clearly not advocating support for all the aforementioned listed options, limiting it down to just one seems unnecessarily restrictive.

 

May we invite you consider our proposal of allowing more options for 20 MHz STAs — consistent with what's allowed for 80 MHz STAs. For example

  • Lower 20 MHz of the second 40 MHz in an 80 MHz BSS
  • Lower 20 MHz of the secondary 80 MHz in a 160 MHz BSS
  • One of the lower 20 MHz subbands outside the primary 80 MHz in a 320 MHz BSS (i.e. either the lower 20 MHz of the secondary 80 MHz, lower 20 MHz of the lower 80 MHz of secondary 160 MHz, or the lower 20 MHz of the upper 80 MHz of secondary 160 MHz) shall be a DSO subband

 

While the above text calls out “Lower 20 MHz”, we are open to the possibility that any one 20 MHz subband of a 80 MHz band can be considered. The text corresponding to what a 160 MHz or a 320 MHZ AP can assign, will be derived accordingly.

 

Our aim is to enable meaningful DSO operation for 20 MHz STAs. Given that DSO is meant to improve channel utilization, a fallback to only the immediate adjacent 20 MHz channel (which is often similarly impacted) may offer little benefit in field deployments.

 

We look forward to your thoughts and constructive discussions on meaningful enablement of DSO operation for 20 MHz STAs – particularly in light of the increasing relevance of 20 MHz IoT devices, which are growing at a CAGR of 13–15%.

 

Thanks and Kind Regards

Rakesh

 

 

From: Morteza Mehrnoush <morteza.80211@xxxxxxxxx>
Sent: Thursday, July 24, 2025 6:04 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] DSO PDT and CR doc 11-25/1164

 

CautionThis e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guide to help you identify Phishing email.

 

Hi all,

 

Please review the PDT/CR doc for DSO and let me know if you have any comments.

 

Thanks,

Morteza


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