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

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

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