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

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

Thread Links

Date Links

Thread Prev

To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx

Subject: Re: [STDS-802-11-TGBN] MAC PDT generic enablement

From: Gaurang Naik <0000305a2f8ce933-dmarc-request@xxxxxxxxxxxxxxxxx>

Date: Fri, 25 Jul 2025 06:10:59 +0000

Hi Vishnu,

Thank you for reviewing and providing your comments. Please see my responses inline.

Thanks,

Gaurang

From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Thursday, July 24, 2025 10:49 PM
To: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: RE: 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 the contribution. Just some high level points:

Terms of “OMP Request” and “OMP Response” should have UHR in them.

[Gaurang] Don't think this is needed but I can add it.

Why define separate element for AP side (UHR Parameters Update element) and for non-AP side (UHR Mode Change element). Better build a unified design that uses a single element for both AP and non-AP side.

[Gaurang] I am personally fine with defining the same element for AP and non-AP side. However, I have had other members express their opinions that they do not prefer such an approach. While drafting the two PDTs, I realized that (a) it can be made to work, and (b) it can complicate the text writing and parsing, both. For now, I am inclined to use two separate elements given the past feedback from multiple members.

Using the mode length to indicate whether mode is being enabled/disabled is not a good design in my opinion. It can limit generalization in future when specific lengths are needed. Better to have separate field indicating enabled/disabled that is not linked to length field.

[Gaurang] Since I had similar comments mentioned by few members, I am discussing offline with additional members and working on a proposal to address this. I will provide the details in a separate email.

Why do we need a configurable timeout interval for each AP? Is specifying a spec defined value not sufficient?

[Gaurang] I see this as essentially the same question as: why can't the specification define a single padding delay value for DPS, DSO, EMLSR, etc.? My assumption is that this value is implementation- or configuration-dependent. A fixed value in the spec would likely either limit flexibility or result in inefficiencies, as it may not suit all implementations. Not clear what would be the benefit, any way.

In 2^nd to last paragraph, what is transition timeout?

[Gaurang] It is the timeout value that is initialized to the value obtained from AP's advertised field. Do you have an alternate suggestion?

Regards,

Vishnu

From: Gaurang Naik <0000305a2f8ce933-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, July 23, 2025 9:57 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [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.

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