| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Gaurang, Thank you for your response. I see that my 2nd mail permits to clarify my thoughts, that’s fine ! Regarding your analysis, it is right, on one end my proposition can be seen as only saving 1 bit in the EML Ctrl field carried in the EML Notification frame. But, on the other end, my proposition highlights that only one bit is necessary in EML Ctrl field carried in the EML Notification frame to activate/deactivate the mode supported. Moreover, I wonder if my proposition really adds a requirement at the AP MLD side : -Indeed, even with the current signaling using 2 bits in the EML Ctrl field, the AP MLD will have to check the information provided by the non-AP MLD in the EML capabilities during the Association: the AP MLD
needs to retrieve the EMLSR delay value (in case of EMLSR activation) or to retrieve the EMLMR Delay and the Tx/Rx NSS values (in case of EMLMR activation). So, checking the EMLSR support bit and EMLMR support bit values prior to retrieving these listed parameters
values seems not to be a big additional requirement. -Also, with the current signaling using 2 bits in the EML Ctrl field, while receiving an EML notification frame with both EMLSR mode bit and EMLMR mode bit set to 0, the AP MLD may also need to check the EML
capabilities to know which mode is deactivated. Best regards Mike From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx> Hi Mike, Thank you for the follow up and for the clarification. I understand your point now. However, why not keep the information in the frame self-contained? As per your proposal, the AP knows from its past reception of the Association Request frame that the non-AP supports one of the two EML modes
(EMLSR or EMLMR). When the AP receives the EML notification frame, it would know which of the two EML modes is being enabled or disabled. This requires the AP to first check which of the two modes the transmitting non-AP supports and enable/disable that mode
for the non-AP. In my opinion, it is an optimization that adds requirement at the AP at the benefit of saving only 1 bit. Using the format currently defined in the spec, the AP immediately knows which of the two EML modes is being enabled/disabled, and so
it is a much simpler approach. Thanks, Gaurang From: LORGEOUX Mickael <Mickael.Lorgeoux@xxxxxxxxxxxx>
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 feel that my first email was not so clear, let me clarify my thoughts : -Regarding the Support of modes in the EML capabilities, the intention is to keep both EMLSR support bit and EMLMR support bit and to keep also the same encoding for AP MLD and non-AP MLD. -Regarding the Activation/Deactivation of modes in the EML ctrl field carried in the EML notification frame, the intention is to use only 1 bit (EML mode bit) instead of 2 bits (EMLSR mode bit and EMLMR mode
bit) as in the current draft. As the document 1703r0 clarifies that a non-AP MLD cannot set both EMLSR support bit and EMLMR support bit to 1 simultaneously in the EML capabilities subfield, the use of only 1 bit (EML mode bit) in the EML
Ctrl field carried in the EML notification frame is sufficient to activate either the EMLSR mode (if EMLSR support bit is set to 1) or the EMLMR mode (if the EMLMR support bit is set to 1) on a non-AP MLD. I hope this clarifies. Best regards Mike From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Hi Mike, Thank you for reviewing the documents and providing your feedback. Regarding the point you raised, it is a good one. I did think about it. However, even though the non-AP may not support both EMLSR and EMLMR modes simultaneously, the AP can. So, we need two bits for the AP. As a result, if we are to indicate
the support for EMLSR/EMLMR through a single bit for a non-AP, the encoding will be different for AP and non-AP, which might be an unnecessary optimization.
Furthermore, encoding using a single ‘EML Mode’ subfield might be a little counter-intuitive in my opinion. If the bit is set to 0, typically it would mean EML Mode is not supported, which is not the intention here. Thus, I believe the current encoding is appropriate even though an additional bit is used. We could definitely work toward providing further clarifications in the text so that there are no confusions.
Kindly let me know your thoughts. Thanks, Gaurang From: LORGEOUX Mickael <Mickael.Lorgeoux@xxxxxxxxxxxx>
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 sharing us these 2 documents. Regarding the document 1703r0, I have the following remark: The resolution of the CID#7578 clarifies that a non-AP MLD cannot support both EMLSR mode and EMLMR mode simultaneously in the EML capabilities subfield. This being clarified, it seems that having both EMLSR mode and EMLMR mode bits in the EML control field is not necessary and may be even confusing. Indeed, having only one bit, called for example EML mode, in the EML control field is sufficient
to activate either the EMLSR mode (if EMLSR support bit is set to 1) or the EMLMR mode (if the EMLMR support bit is set to 1) on a non-AP MLD. Please let me know if my understanding is correct or not. Best regards Mike From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Hi all, I have uploaded r0 of documents
1702 and
1703 on the server. Please let me know if you have any feedback. Thanks, Gaurang From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Alfred, Could you please add the following two documents to the MAC queue? I will upload the docs soon.
Thanks, Gaurang From: Cariou, Laurent <laurent.cariou@xxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Alfred, Please add doc 1562 in the queue for MAC call. Thanks, Laurent From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Hello all, I uploaded an updated version of the agendas, which contains the agenda for the next conference calls, scheduled on Monday
October 18 (MAC/PHY), 19:00-21:00 ET, Wednesday October 20 (MAC), 10:00-12:00 ET and Thursday October 21 (MAC), 10:00-12:00 ET. PS: Please note the conversion of the conf call of Wednesday from Joint to MAC ad-hoc. The agendas can be found here: https://mentor.ieee.org/802.11/dcn/21/11-21-1478-17-00be-sept-nov-tgbe-teleconference-agenda.docx Note for CR documents: Please update the baseline to TGbe D1.2 (available in the member's area) for the CR documents. Alternatively, please ensure that
there are no conflicts between the proposed changes in the CR documents and TGbe D1.2. DIAL IN DETAILS FOR MONDAY: Join the MAC meeting here: https://ieeesa.webex.com/ieeesa/j.php?MTID=mf773d5c9fe8b57eec87e24486f11bc95 Meeting number: 233 331 82254 Meeting password: wireless (94735377 from phones and video systems) Join the PHY meeting here: https://ieeesa.webex.com/ieeesa/j.php?MTID=m1f986061bfb36f8dcd2e4a81efc5ae27 Meeting number: 234 412 17121 Meeting password: wireless (94735377 from phones and video systems) DIAL IN DETAILS FOR WEDNESDAY: Join the MAC meeting here: https://ieeesa.webex.com/ieeesa/j.php?MTID=mb4461315b1f40e2d01f609734002daca Meeting number: 233 711 92740 Meeting password: wireless (94735377 from phones and video systems) DIAL IN DETAILS FOR THURSDAY: Join the MAC meeting here: https://ieeesa.webex.com/ieeesa/j.php?MTID=md0721629ef4c19c3dfb03868d0e1a162 Meeting number: 233 029 16155 Meeting password: wireless (94735377 from phones and video systems) Let me know if you have any questions and/or suggestions. Best Regards, Alfred -- Alfred Asterjadhi, PhD IEEE802.11 TGbe Chair, Qualcomm Technologies Inc. Cell #: +1 858 263 9445 Office #: +1 858 658 5302 To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |