| Hi Gurang,
Thanks for updating the document.
In the latest version r14 of 882, the “In-device coexistence activities” is still missing and should be added to the following list on page 21, as a part of the 11be EMLSR function.
%------------- - EMLSR link bitmap - EMLSR padding delay - EMLSR transition delay %—————— Best Regards, Qi On Jul 30, 2025, at 2:56 PM, Gaurang Naik <0000305a2f8ce933-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Alfred,
Could you please schedule document 11-25/882 for SP?
Thanks, Gaurang
From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Wednesday, July 30, 2025 3:53 AM
To: Chittabrata Ghosh <chitta.ghosh@xxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] MAC PDT generic enablement
Hi Chitto,
The feedback I received suggested that, either later in 11bn or in future amendments, if there's a need to define additional control information for different modes, it would be more flexible to keep these bits mode-specific. From a technical standpoint, this approach makes sense to me, and I don’t see any reason to oppose the suggestion.
That said, I don’t have a strong preference either way. I’m trying to balance different perspectives and help move this topic forward, so I’d really appreciate your cooperation as we work through this.
Thanks, Gaurang
From: Chittabrata Ghosh <chitta.ghosh@xxxxxxxxx>
Sent: Wednesday, July 30, 2025 3:42 AM
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,
I am not sure I understood "flexible encoding per-mode in future, if needed." in relation to the Mode Specific Control field definition. Could you please explain about this flexible encoding per mode? As of now, there is no normative text defined for any UHR mode.
I do not see a compelling reason to define this mode. In future, if there is need, the Reserved field can be repurposed for new definitions. My suggestion is to still keep it Reserved.
Best Regards, Chitto
Hi Chitto,
Thank you for your review and feedback.
Please see my responses inline.
Thanks Gaurang
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 updating the document to r14. Splitting the OMP Operation field into Mode Enable and Mode Update is definitely clean.
Some of the editorial suggestions are as follows: 1) Do we need a "Mode Specific Control" field in the Mode Control field? I reviewed the text related to this field for each mode and it is reserved for all the modes. In that case, could we keep the 6 bits (B2-B7) as Reserved instead? This was done based on offline feedback and I believe it is reasonable because it allows for flexible encoding per-mode in future, if needed. I will keep it as is for now. 2) In the figure for the Mode Control field format, please replace B8 with B7. Thanks for the catch. Will fix in next revision.
Best Regards, Chitto
Hi all,
I have uploaded document 11-25/882r14 that incorporates almost all the feedback that I received during the presentation yesterday. Changes include: - Split OMP Operation field into two bits – one for enable/disable and another for update
- Removed duplication of the Table on OMP Operation encoding
- Removed “Parameterized mode” field in the Mode Control field of DPS
Added clarification text in Reconfig ML element subclause to remove conflict between this document and baseline Removed the figure in the Mode Specific Parameters for AOM subclause as it is defined in 11-25/744
I am still having offline discussions on two other items (viz. in-device coex activities bit and DBE) and more updates may follow. However, in the meantime, I wanted the group to verify the changes in the element format. Please let me know if you have any feedback.
Thanks, Gaurang
Hi Liuming,
Thank you for your review and comment. Please see my responses in the attached. I will make one change as I indicated, which will appear in r13.
Thanks, Gaurang
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Gaurang, Thanks for your hard work on this document. I attach some further comments. Best regards, Liuming Lu Hi Liuming, Thank you for reviewing the document and providing your comments. I saw your email after I sent out the other updates. Most of your comments are addressed in r10. Could you pls review? Please see my responses in the attached. Thanks, Gaurang
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Gaurang, Thanks for preparing this document. I attach some comments. Best regards, Liuming Lu Hello all, Could you please use this thread to provide your feedback/comments on document 882r9? Thanks, Gaurang
Hello all, Thanks, Gaurang
Hello all, Thanks, Gaurang
Hello all, Uploaded 11-25/882r6 based on received offline feedback. Thanks, Gaurang
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
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
|