Re: [STDS-802-11-TGBN] Discussion on DSO CR Presentation 25/0793r1

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

Hi Sindhu,

Thanks for your feedback. I removed the capability bit and made the corresponding changes to the DSO section, also taking others' opinions into account.

Hi all,

Kindly review the revised document, available on the server, or as attached. Thanks

On Thu, 2 Jul 2026 at 18:07, Sindhu Verma <sindhu.verma@xxxxxxxxxxxx> wrote:

Hi Yuxin,

Thanks for preparing this new version.

What is the purpose of the capability bit “NSTR status indication for DSO” if the existing mechanism for NSTR update will be used by the non-AP MLD? This capability indication is of no use to the AP.

I think you can just add a note that a non-AP MLD may indicate/update the NSTR status of the links when DSO is supported or enabled in view of “all potential DSO subbands that it may switch to in order to perform DSO frame exchanges as its operating subband in addition to the primary subband, following the rules defined in 35.3.16.2 MLD capability and operation signaling”. Other changes are not needed in my opinion.

Regards,
Sindhu

On Thu, Jul 2, 2026 at 8:33 AM yuxin.lu <eeluyx@xxxxxxxxx> wrote:
Hi Sindhu,

Thanks for your further suggestion. I can agree to your resolution to indicate the STR/NSTR relation upon association using legacy signaling, by considering all potential DSO subbands as its operating subbands, in addition to the primary subband, and corresponding changes have been made. Also, the capability bit is preserved to let the DSO non-AP STA choose between the DSO advantage and the NSTR disadvantage

Hi all,
Kindly review a revision of this document, available on the server, or as attached. Thanks

On Wed, 1 Jul 2026 at 18:21, Sindhu Verma <sindhu.verma@xxxxxxxxxxxx> wrote:
Hi Yuxin,

I meant to say that when associating on a set of links, the non-AP is aware of whether an STR relationship exists between them based on its operating bandwidth and whether that relationship will change to NSTR if the entire BSS bandwidth gets used. Optimizing this for every DSO subband every time DSO is enabled is an overkill. As I also mentioned, it is straightforward for the non-AP to choose whether to keep a set of STR links without DSO or keep a set of NSTR links with DSO.

So, I suggest the following options in this scenario:
The non-AP MLD defines the STR/NSTR relationship based on BSS bandwidth if both the AP and non-AP support DSO.
The non-AP MLD may choose to define an STR relationship between 2 links based on its operating bandwidth. If that can change to NSTR, it doesn’t enable DSO as DSO+NSTR is not definitively better than STR
Secondary option (less preferred): Define a mechanism at association to indicate a link relationship without DSO using operating bandwidth as well as with DSO using BSS bandwidth.

Regards,
Sindhu

On Wed, Jul 1, 2026 at 11:19 AM yuxin.lu <eeluyx@xxxxxxxxx> wrote:
Hi Sindhu，

Thanks for your detailed response and suggestions. Please see my reply in-line in purple below

On Tue, 30 Jun 2026 at 17:51, Sindhu Verma <sindhu.verma@xxxxxxxxxxxx> wrote:
Editing the subject slightly and adding the TGbn mailing list

Hi Yuxin,

Thanks for reaching out.

The use case you are describing can have only the following options:
There is a non-AP MLD which has an STR relationship between a link in 5GHz and a link in 6GHz (because that is where DSO can be enabled) . That STR relationship can turn to NSTR when DSO is enabled. However, there can never be a possibility of an NSTR relationship turning to STR. The mechanism you are proposing to define covers possibilities in both directions and hence, not suitable
[Yuxin] I agree that this status change can only happen to links in 5 GHz or in 6 GHz. If the DSO subband of link 1 is farther from the primary subband of link 2 compared with the primary subband of link 1 from that of link 2, the relation may change from NSTR to STR because the frequency separation is enlarged, right? But I agree this is not the bottleneck case
Even then, the NSTR or STR relationship for a pair of links with a certain bandwidth is supposed to be static across multiple enablements and disablements. Again, the mechanism you are proposing allows for a dynamic change in this relationship every time DSO is enabled or disabled.
[Yuxin] The NSTR or STR relationship depends on the location of the DSO subband, which is negotiated via the OMP procedure. I suppose the NSTR or STR relationship needs to be signaled together with the OMP procedure (my initial proposal in r1). But as you suggested, it should remain the same until the DSO subband is renegotiated. Another option is that the non-AP STA signals its NSTR status by considering the AP's operating bw as its own, which I think may not be very reasonable and is inefficient.
Hence, I request you to reconsider your design and at most propose a static negotiation mechanism which is usable only if the non-AP MLD is already STR between a pair of links. The negotiation of the worst case relationship is also a good alternative as it is not clear if 2 NSTR links with DSO on one or both of them can give gains over 2 STR links without DSO.
[Yuxin] Thanks for this recommendation. In summary, the negotiation of the worst case relationship can be done together with the negotiation of the DSO subband via the OMP procedure, and remain the same until the DSO subband is renegotiated. What do you think?

Regards,
Sindhu

On Fri, Jun 26, 2026 at 1:06 PM yuxin.lu <eeluyx@xxxxxxxxx> wrote:
Hi Gaurang, Morteza, Sindhu, and Dibakar,
cc Mikaël,

This is Yuxin from TCL.

Thanks for your comments during yesterday's joint call. Didn't have time to respond then. Let me reply together here for efficient communications before continuing the discussion next Thursday.
Correspondingly, a revised revision of CR 25/0793 is attached per your comments and my reply below. Please kindly review it and let me know your further recommendations. Thanks a lot.

Q from Gaurang: Why can't the non-AP MLD use the frame that was defined in 11be? Put other way, are there any changes needed to handle this case？
[Yuxin] This NSTR update is effective along with the DSO enablement, so it would be more effective to send it as DSO parameters (which is a one-round handshake), compared to sending it using a separate signaling (which requires a two-round handshake)
If you prefer a two-round handshake, using the legacy frame, I suppose it also works, but it is less efficient.
Please refer to the attached document, which addresses your comments. Thanks

Q from Morteza: When enabling DSO, non-AP STA can indicate its NSTR status based on worst case, using the current mechanism
[Yuxin] As replied to Gaurang, using the legacy frame also works, but is less efficient, since it requires a two-round handshake: UHR OMP request/response, EHT NSTR status update procedure.
Agree with you that the NSTR status can be based on the worst case, and it requires additional capability to determine this worst case result. Therefore, it is necessary to indicate a new capability instead of mandating every DSO non-AP to do this.
Please refer to the attached document, which addresses your comments. Thanks

Hi Sindhu:
Please review the revised doc and provide your comments. Thanks

Q from Dibakar: STA is NSTR during DSO and STR otherwise？
[Yuxin] Indeed, this is the bottleneck case where the AP MLD is unaware of such a status change, does not follow the NSTR transmission limitations during DSO, and transmission may fail or interfere with the other link. The DSO subband is beyond the operating bandwidth of the non-AP STA, so this certainly may happen.

Have a good day. Looking forward to hearing from you. :)

--
Best Regards,
Yuxin

--
Best Regards,
Yuxin

--
Best Regards,
Yuxin

Best Regards,

Yuxin

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