Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Thanks Rojan for your reply.. I consider MLME/SME as an abstract interface and there could be many implementation choices to manage the processing delay, so in my mind it doesn’t mean that immediate reporting (of course >>SIFS and possibly tens/hundreds of us) cannot
be achieved even with report being sent to SME and authorized to be sent back over-the-air.
From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Claudio, Solomon, Ali, and all, Thank you for the clarification on this topic in this thread and the other one as well by Solomon and Ali. I may have missed the fine print on the motion and wasn’t aware that this was already discussed in 11bf, my apologies. I have no
issue regarding passing up the Measurement results to SME for local reporting case, I believe that is natural. My question/concern was more regarding the case where the Measurement results needs to be sent back to the Initiator. If this is triggered by the
SME (thru MLME), there will be a large delay (e.g. compared to SIFS reporting) between the actual measurement and the reporting (possibly several tens of milli-seconds if not more). In addition, this would also mean the upper layer needs to buffer the measurement
results (one or more instances) and also is responsible for the actual triggering of the reporting. Is this the right understanding? I just want to make sure we are all on the same page. Perhaps this makes sense for Delayed reporting, but isn’t this unnecessary
overhead for immediate reporting? This could have adverse effect, especially on latency sensitive applications e.g. fall detection etc. Regards, Rojan From: Claudio Da Silva <000015f3cbee3aeb-dmarc-request@xxxxxxxxxxxxxxxxx>
Rojan, First, thanks for reviewing the document. First, I would like to point out that your question has already been discussed in TGbf and that the group has approved the approach found in the PDT (figure in your email). Specifically, you can find the following statement in page 9 of
the SFD: I will let the folks who advocated for this approach jump in and discuss its technical merits. In the meanwhile, I would like to propose the following:
Thanks, Claudio From: Rojan Chitrakar
rojan.chitrakar@xxxxxxxxxxxxxxxx Hi Claudio, Thanks for the hard work on this. I have a question for the circled portion below (MLME-SENSTBREPOTRQ): While I agree that setup and termination should go up to the SME, I do not understand why the SME needs to be involved in the reporting phase. Shouldn’t this be handled within the MAC? Even for delayed reporting case, I struggle to think
of a reason why the SME needs to be involved. If the SME is involved, does it mean the measurement report is prepared by the SME (and not by the MAC)? There are no such MLMEs for BF reports, and even in 11az, the feedback for FTM is handled within the MAC: Regards, Rojan From: Claudio Da Silva <000015f3cbee3aeb-dmarc-request@xxxxxxxxxxxxxxxxx>
All, I have just uploaded the baseline document for the MLME TTT, which can be found here:
https://mentor.ieee.org/802.11/dcn/22/11-22-0233-00-00bf-proposed-draft-text-for-mlme.docx It should be noted that the contents of this document are still being discussed by TTT. If you have any comments, send me/us a note. We will bring the document to TGbf when appropriate. Thanks, Claudio To unsubscribe from the STDS-802-11-TGBF list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1 To unsubscribe from the STDS-802-11-TGBF list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1 To unsubscribe from the STDS-802-11-TGBF list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1 To unsubscribe from the STDS-802-11-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1 |