Re: [STDS-802-11-TGBF] Baseline document for the MLME TTT

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

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>
Sent: Tuesday, February 8, 2022 5:24 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBF] Baseline document for the MLME TTT

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:

Since the contents of the MLME PDT are perfectly aligned with the SFD, I’ll go ahead and add the document to the presentation queue.
Rojan: If you would like to re-open this discussion and propose an approach different from the one defined in the SFD, please bring a contribution to TGbf. We can certainly modify text accepted into D0.1 if there is agreement. It is just a matter of proposing specific modifications and following 802.11 procedures.

Thanks,

Claudio

From: Rojan Chitrakar rojan.chitrakar@xxxxxxxxxxxxxxxx
Sent: Sunday, February 6, 2022 8:56 PM
To: Claudio Da Silva <claudiodasilva@xxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: RE: Baseline document for the MLME TTT

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>
Sent: Saturday, January 29, 2022 2:24 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBF] Baseline document for the MLME TTT

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