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

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



Hi Gaurang,

 

Thank you for the changes. I generally agree with you that the need for separate encoding for “Update” vs “Enable” may not be needed, but I am open to it. One thought is that the number of “sub-modes” is different for each feature, e.g., DPS has basic and parameterized mode, which need separate indication. Similarly there may be other Control fields which are feature specific.

So better have the whole of the Mode Parameters field (including the Mode Control) be feature-specific, as opposed it being kept generic. So the Mode Control can also be described for each feature in clauses 9.4.2.X.1/2/3.. etc (as is the case with Mode specific parameters).

 

Regards,

Vishnu

 

From: Gaurang Naik <0000305a2f8ce933-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, July 25, 2025 4:38 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] [STDS-802-11-TGBN] MAC PDT generic enablement

 

Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

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.

Id 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 designsfor 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 fieldits intended to support forward compatibility in case future amendments introduce additional parameters. Assuming that future amendments wont 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 Id like to understand the underlying rationale or design philosophy behind using the Length field

to distinguish between enablement (or update) and disablementregardless 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] Isnt 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, its for initial setup.

[Seongho] Yes, thats 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 its reasonable to specify that while an OMP request is in progressi.e., the AP hasnt responded yet or the timer hasnt expiredthe 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

 

 

cid:image001.png@01DBFD40.4D8074C0


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

 

 

cid:image001.png@01DBFD40.4D8074C0


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