|
|
Mode Control
|
Mode Specific Parameters
|
|
Octets:
|
1
|
variable
|
|
|
B0 B1
|
B2 B7
|
|
|
OMP Operation
|
Reserved
|
|
Bits:
|
2
|
6
|
|
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.
-
-
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).
-
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.
-
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.
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>
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.
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>님이 작성:
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