Re: [STDS-802-11-TGBN] MAC CR document for enablement/disablement of mod

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

Hi Binita,

Thank you for reviewing the PDT and providing your comments.

Please see my comments inline.

Thanks,

Gaurang

From: Binita Gupta <bingupta.ieee@xxxxxxxxx>
Sent: Thursday, July 24, 2025 3:11 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] MAC CR document for enablement/disablement of modes on AP side

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

Hi Gaurang,

Attached please find my inline comments on 1091r3.

I have 3 fundamental concerns with the PDT proposal:

1) I see that the current format defined does not allow including more than 14 octets for CU parameters, which as I indicated earlier is very limiting for DBE, since DBE CU also needs to provide TPE info for the expanded DBE BW.

Hence, we need to define a more flexible format using Sublement ID + subelement Length.

[Gaurang] The goal was to have a compact design that does not add overhead to the beacons. Yes, with 14 octets, while some subelements can be added, not all can (such as TPE with the PSD interpretation).

I believe that for each mode, we should limit the number of parameters that can be advertised because that adds considerable overhead to the beacons, which is what the group is consciously trying to avoid, as you are aware. Naturally, if it is deemed absolutely necessary then the design will need to accommodate that. So far, other than DBE (for which you mention that TPE element is required), I don't see the need for exceeding 14 octets.

Coming to DBE, my question is --- can we not carry the TPE information for the additional bandwidth within the legacy TPE element itself? Do we need to carry a new TPE element as a subelement?

2) We need to allow including at least two UHR Parameters Update elements, one indicating critical updates that is going to take effect in future + one indicating CUs that have taken effect in the past.

[Gaurang] I disagree with this comment. We should have just one UHR Parameters Update element that is inserted in the Beacons when the update is first announced. Thereafter, until that element is included, the AP must not advertise additional updates. Adding multiple elements (some that announce future updates and some that announce past updates) will lead to significant beacon bloating and we need to actively avoid that.

3) For the broadcast Probe Response that includes UHR Parameters Update element, we need to capture the requirement that the broadcast addressed Probe Response is MIC protected to protect integrity of these parameters.

[Gaurang] This seems orthogonal to the topic of my PDT. I am open to discussing it further, but I believe this needs to be addressed in a separate contribution.

Could you please review and address these comments.

Thanks,

Binita

On Thu, Jul 24, 2025 at 10:32 AM Binita Gupta <bingupta.ieee@xxxxxxxxx> wrote:

Hi Gaurang,

Thank you for this revised PDT.

You are using the TLV format with 4-bits length for AP side parameters, same as STA slide parameters in generic enable/disable, but this is limiting for AP side.

Consider the DBE case - for DBE, AP may also need to update TPE information for DBE BW (say for 320 Mhz). Ty[ically AP includes multiple TPE elements to provide local and regulatory max transmit powers. An EIRP TPE element is 5 octets of content and a PSD TPE element is 16 octets of content. Even two such TPE. elements would not fit within the 16 octets length, so this scheme won't work in this specific case.

We need to design a more flexible format for AP side Critical parameters update - we should use a supplement format with 1 octet length field.

Please address this issue.

Thanks,

Binita

On Wed, Jul 23, 2025 at 5:56 PM Gaurang Naik <0000305a2f8ce933-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hello all,

Could you please use this thread to provide your feedback/comments on document 1091r3?

Thanks,

Gaurang

From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Wednesday, July 23, 2025 3:44 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <stds-802-11-tgbn@xxxxxxxxxxxxxxxxx>
Subject: Re: MAC CR document for enablement/disablement of modes on AP side

Hello all,

11-25/1091r3 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 CR document for enablement/disablement of modes on AP side

Hello all,

11-25/1091r2 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 CR document for enablement/disablement of modes on AP side

Hello all,

Uploaded 11-25/1091r1 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: MAC CR document for enablement/disablement of modes on AP side

Hello all,

I have uploaded CR 11-25/1091r0 that resolves CIDs on enablement/disablement of UHR features on the AP side. The CR document resolves the following CIDs:

2512, 2479, 2692, 913, 3405, 2473, 3652, 3680, 2124, 3802, 3801

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

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