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

Re: [STDS-802-11-TGBN] MAC CR document for enablement/disablement of modes on AP side

Hi Gaurang,

Thank you for the responses.
Please see further comments below.

Thanks,
Binita


On Fri, Jul 25, 2025 at 7:46 AM Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx> wrote:
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. 
<BG> 14 octets is limiting. We already have the use case for DBE to advertise TPE. In the future there can be other use cases. We are designing a new scheme and it should be designed such that it provides future flexibility to support larger parameters size. Else, for parameters that don't fit in the 14 octets limit, we would need to start defining new elements and carry those in beacons. That would add element overhead. 

So, I think the best balance is to define a larger length field now to have the flexibility. 


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? 

<BG> Including TPE info for wider DBE BW all the time in the TPE elements in the beacon would add much more overhead to beacon, which is what we are trying to avoid. This will reset beacon bloating optimizations we are trying to achieve through other means. There can be multiple TPE elements included - around 5 or 6 TPE elements may need to be provided for EIRP based TPE, PSD based TPE for local and regulatory max transmit powers.  For a 40 Mhz BSS BW with DBE BW of 320 MHz, this would add an extra 14 octets in one PSD based TPE element (14* PSD for each additional 20 Mhz subband). If multiple TPE elements are included then overhead is multiplied and is carried in the beacon always. So that would be a concern.

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.  

<BG> It is not a good direction to limit this. I think other critical updates can happen while AP is providing parameters for an extended period of time to avoid Probe Req/Resp. We need to at least allow two elements. 

Also, within an ongoing CU element for advance notification, there can be other OM critical updates added. E.g. if a CU element is providing advance notification for OM1 and an update needs to be announced for OM2, then AP can add that to the current CU element. The framework needs to define that aspect.

 
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. 

<BG> The PDT covers the following text on this point, so this is relevant for the PDT and should be addressed.

"An AP that includes the UHR Parameters Update element in its Probe Response frame should set the Address 1 field [b1] of the frame to the broadcast address, except if explicitly stated otherwise."



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

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