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

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

Hi Manasi,

I had to cut short my previous email because the discussions started.

Regarding the statement:

>> When the value of the Mode ID field is 2, the Mode Specific Parameters field is described in 37.11 (DUO) when present.

This doesn't seem accurate, as the current draft (document 437) does not define any parameters for DUO.

I understand that you have a proposed document that introduces parameters for the OMP request when DUO mode is enabled. I also assume that this proposal will include updates to section 37.11 to define what those parameters represent. If that’s the case, wouldn’t the same document also revise the following statement? The statement below does NOT preclude future edits to it, so I don’t share your concern about its current wording.

>> When the value of the Mode ID field is 2, the Mode Specific Parameters field is not present.

Thanks,

Gaurang

From: Manasi E <emanzee@xxxxxxxxx>
Sent: Friday, July 25, 2025 6:37 AM
To: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] [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.

Thanks Gaurang.

Regarding 2nd comment, what I mean is , there is still some discussion on going about whether we want to include mode parameters for features like DUO.

The current draft spec should not restrict this possibility.

I have raised this concern earlier too and also shared relevant information on this.

So the suggestion is to keep the text generic like having a reference to corresponding section like 37.11 and have a way to enable it in future once we have consensus.

The current text seems to restrict this possibility by specifying like below in red.

9.4.2.X.3 Mode Specific Parameters for DUO

When the value of the Mode ID field is 2, the Mode Specific Parameters field is not present.

Regards

Manasi Ekkundi

On Fri, 25 Jul, 2025, 16:05 Gaurang Naik, <gnaik@xxxxxxxxxxxxxxxx> wrote:

Hi Manasi,

Your first comment generally makes sense. I think instead of updating the second statement, I can remove the 2^nd statement altogether as it does not seem to add much value.

Regarding your second comment, I am not sure I understand what you mean by restricting development of the feature. The text I have for the subclause is aligned with CR document 437, which seems to be the latest version on DUO PDT.

Thanks,

Gaurang

From: Manasi E <emanzee@xxxxxxxxx>
Sent: Friday, July 25, 2025 5:18 AM
To: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] [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

Thanks for the document with updated changes.

I think the Mode Length field needs further clarification as the length depends not only on the Mode ID, but it depends on the OMP Operation in Mode Control.

For example, Disable need not carry any Mode Parameters field. Have suggested modification in blue.

The Mode Length field indicates the number of octets in the Mode Parameters field. The value of the Mode Length field depends on the value of the Mode ID field and the OMP Operation in Mode Control field for that mode tuple.

For example

When DPS is disabled , the below text implies that Mode Specific parameters are present.

9.4.2.X.1 Mode Specific Parameters for DPS

When the value of the Mode ID field is 0, the Mode Specific Parameters field carries the parameters for DPS.

The Mode Specific Parameters field for DPS is the same as the DPS Operation Parameters field defined in 9.4.1.85 (DPS Operation Parameters field).

Hence given that Mode Length clearly indicates when it will be set, do we really need to put a text that so and so mode ID does not carry Mode parameters field?

This ends up restricting developing the feature in future.

Example:

9.4.2.X.3 Mode Specific Parameters for DUO

When the value of the Mode ID field is 2, the Mode Specific Parameters field is not present.

9.4.2.X.4 Mode Specific Parameters for P-EDCA

When the value of the Mode ID field is 3, the Mode Specific Parameters field is not present.

How about replacing like below

9.4.2.X.3 Mode Specific Parameters for DUO

When the value of the Mode ID field is 2, the Mode Specific Parameters field is described in 37.11 (DUO) when present.

I had shared some offline material to you to harmonize on this aspect earlier too.

Also this helps in making it uniform. Do not see why we need to describe mode parameters for one feature like NPCA and not define for others in DPS in this section of specification.

and similarly for others.

Regards

Manasi Ekkundi

On Fri, 25 Jul, 2025, 12:38 Gaurang Naik, <0000305a2f8ce933-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi Seongho, Zhenpeng, Vishnu, all,

Following the feedback I received from you and others offline, I’ve revised the format of the UHR Mode Change element—specifically the Mode Parameters field within the mode tuple. These updates aim to address most of the comments shared so far. I’ve tried to find a common ground among differing perspectives, so not all suggestions may be fully incorporated. I’ve addressed the individual comments separately at the end of this email.

I have incorporated these changes and uploaded 11-25/882r10.

Note that these changes are for the UHR Mode Change element defined in 11-25/882. I will continue the separate discussions on the UHR Parameters Update element defined in 11-25/1091.

Summary of Changes

The overall structure remains the same, with the key update being the revised Mode Parameters field:

Mode Control

Mode Specific Parameters

Octets:

1

variable

Format of the Mode Parameters field

Mode Control Field Format:

B0          B1

B2         B7

OMP Operation

Reserved

Bits:

2

6

Format of the Mode Control field

OMP Operation field Encoding:

OMP Operation field value

Meaning

00

Disable

01

Reserved

10

Enable

11

Update

Here, the first bit indicates enable/disable.

The second bit distinguishes between a "fresh" enable and an update.

The above design takes into consideration the following comments:

Avoids using “Mode Length” to distinguish between enable/disable/update.

Explicitly distinguishes a fresh enable from an update (I am personally not convinced this is needed but I am okay if the group is okay with the approach).

Comments that are not addressed:

4 bits vs 6 bits for Mode ID: Retained as 4 bits. Reserved bits should suffice for future expansion. I heard several offline opinions to keep the Mode ID as 4 bits.

Explicit Parameters Presence Bit: Not added. The value in the Mode Length field implicitly indicates presence.

Need for Mode Length field: Unchanged. The TLV-style design is beneficial for parsing and future compatibility in the event we add more parameters to the existing modes.

Enabling EMLMR mode: Unchanged for now. EMLSR was added based on multiple explicit requests. I can do the same for EMLMR if members are interested.

Additional changes:

Updated the text corresponding to EMLSR enablement

Added the suggested rule to refrain sending one OMP request while previous OMP request is being processed.

Changed OMP request to UHR OMP request.

Thank you for the productive discussions and please let me know if you have additional comments.

Thanks,

Gaurang

From: 변성호 <sh.byeon@xxxxxxxxxxx>
Sent: Thursday, July 24, 2025 4:55 AM
To: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: RE:(2) [STDS-802-11-TGBN] [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,

Thank you for your response.

I’d like to follow up with a few additional thoughts/comments.

Please see the inline.

Thanks!

Regards,

Seongho.

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

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

Date : 2025-07-24 19:13 (GMT+9)

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

Hi Seongho,

Thank you for your comments during the call and reiterating the points over email.

Please see my responses inline.

Thanks,

Gaurang

From: 변성호 <sh.byeon@xxxxxxxxxxx>
Sent: Thursday, July 24, 2025 12:40 AM
To: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: RE:(2) [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,

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.

[Seongho] I agree. Forward compatibility is an important design choice, but it cannot always take top priority.

My comment was intended to double-check whether the current design is wasting valuable bits by assigning meaning to the Length field,

which may not carry meaningful information at this stage. If the group reaches broad consensus, I will of course support the decision.

One remaining point (as mentioned in my earlier question) is that I’d like to understand the underlying rationale or design philosophy behind using the Length field

to distinguish between enablement (or update) and disablement—regardless of forward compatibility.

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.

[Seongho] Yes, that’s quite clear. However, similar to many existing mechanisms,

I believe distinguishing between enablement and update with forward compatibility in mind would result in a better design, which is why I left the comment.

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.

[Seongho] Thank you for your positive consideration.

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

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