Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] MAC PDT generic enablement

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

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Gaurang,

Thank you very much for preparing this document, again :)

I'm reaching out to follow up on the topic we discussed yesterday, as I have a few additional points I'd like to explore.

1. As mentioned yesterday, since the Mode ID determines the structure of the Mode parameter field, it is currently not variable in length.

Because of this, I believe the information conveyed by the Mode Length is quite limited.

While I agree that including the length field offers benefits in terms of forward compatibility and implementation convenience,

I have concerns about whether a variable-length Mode parameter field will realistically be adopted in future designs—for example, if Update shares the same field structure as Enablement.

Additionally, I do not agree that using special values for the Mode length field to indicate Enablement or Disablement is a good design approach.

[Gaurang] I think your question actually highlights the rationale for using the Length field—it’s intended to support forward compatibility in case future amendments introduce additional parameters. Assuming that future amendments won’t build on a forward-compatible design feels a bit pessimistic.

2. Using a unified approach for enablement and update introduces ambiguity, making it unclear whether a feature is being activated for the first time or simply modified.

This can lead to state confusion on both the AP and client side, especially when verifying current feature status.

Additionally, it may limit protocol scalability by restricting future extensions that differentiate between setup and dynamic reconfiguration.

[Gaurang] Isn’t it already clear to the receiver which type of request is being made? Since the AP knows whether the mode is currently enabled, it can infer the intent: if the mode is already enabled when the frame is received, the request is for an update; otherwise, it’s for initial setup.

3. How about prohibiting further updates to a mode that is part of an ongoing OMP procedure with an active timer?

It might also be necessary to specify a timer reset procedure — for instance, when the AP receives an acknowledgment for the OMP Response or when the non-AP STA transmits the acknowledgment.

[Gaurang] I believe it’s reasonable to specify that while an OMP request is in progress—i.e., the AP hasn’t responded yet or the timer hasn’t expired—the non-AP STA must refrain from sending another OMP request. This can help prevent race conditions, especially when both requests aim to update the same mode. I will update the PDT to add this behavior.

Thanks,

Regards,

Seongho.

--------- Original Message ---------

Sender : Gaurang Naik <0000305a2f8ce933-dmarc-request@xxxxxxxxxxxxxxxxx>

Date : 2025-07-24 11:26 (GMT+9)

Title : Re: [STDS-802-11-TGBN] MAC PDT generic enablement

Hi Yongho,

Thank you for the catch.

I can update the statement to say "A UHR non-AP MLD shall not transmit an EML Operating Mode Notification frame to enable, disable or update the parameters of the EMLSR mode."

Will capture this in my next revision.

Thanks,

Gaurang

From: Yongho Seok <yongho.seok@xxxxxxxxx>
Sent: Wednesday, July 23, 2025 5:09 PM
To: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] MAC PDT generic enablement

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Gaurang,

In 802.11be, the EML OMN frame is used for EMLSR and EMLMR.

A UHR

non-AP MLD shall not transmit an EML Operating Mode Notification frame

Based on this sentence of your PDT, the EMLMR mode can't be used by UHR STA because there is no UHR signaling for EMLMR.

Or, you can add similar signaling for EMLMR mode in your enablement framework.

Could you clarify what your intention is?

Thanks,

Yongho

2025년 7월 23일 (수) 오전 7:57, Gaurang Naik <0000305a2f8ce933-dmarc-request@xxxxxxxxxxxxxxxxx>님이 작성:

Hello all,

Could you please use this thread to provide your feedback/comments on document 882r9?

Thanks,

Gaurang

From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Wednesday, July 23, 2025 3:43 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <stds-802-11-tgbn@xxxxxxxxxxxxxxxxx>
Subject: Re: MAC PDT generic enablement

Hello all,

11-25/882r8 is now on mentor.

Thanks,

Gaurang

From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Tuesday, July 22, 2025 10:29 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <stds-802-11-tgbn@xxxxxxxxxxxxxxxxx>
Subject: Re: MAC PDT generic enablement

Hello all,

11-25/882r7 is now on mentor.

Thanks,

Gaurang

From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Tuesday, July 22, 2025 2:34 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <stds-802-11-tgbn@xxxxxxxxxxxxxxxxx>
Subject: Re: MAC PDT generic enablement

Hello all,

Uploaded 11-25/882r6 based on received offline feedback.

Thanks,

Gaurang

From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Monday, July 21, 2025 3:24 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <stds-802-11-tgbn@xxxxxxxxxxxxxxxxx>
Subject: Re: MAC PDT generic enablement

Hello all,

I have uploaded a rev5 of the document 882. This addresses feedback that I received during the teleconference and over email. It also now resolves the following CIDs:

2478, 2480, 2471, 2648, 2651, 2711, 2712, 3650, 3678, 3952, 721, 2121, 2122, 2123, 252, 2491, 2492, 2591, 2592, 3716, 3764, 1278, 1279, 1280, 1281, 1282

Please let me know if you have any feedback or suggestions.

Thanks,

Gaurang

From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Monday, May 12, 2025 4:14 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: MAC PDT generic enablement

Hi Alfred,

Could you please queue 11-25/882, PDT on generic enablement, to the MAC queue? It resolves ~30 TBDs in D0.2.

All, please review and let me know if you have any feedback.

Thanks,

Gaurang

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