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

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

Thanks

 

Best  regards,

Solomon Trainin

+972547885738

 

From: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>
Sent: Tuesday, February 8, 2022 9:38 PM
To: Solomon Trainin <strainin@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: RE: Baseline document for the MLME TTT

 

A few comments inline..

 

From: Solomon Trainin <strainin@xxxxxxxxxxxxxxxx>
Sent: Tuesday, February 8, 2022 6:40 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBF] Baseline document for the MLME TTT

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Rojan,

Thank you for raising the question.

I believe that the discussion allows a better understanding of the sensing basics.

Please see below my interpretation of the issue.

I see a few differences between ranging and sensing:

In the ranging

  1. the report is of a single type

Correct

  1. the report belongs to the last measurement and is reported in the same "SIFS" instance

Result can belong to the exiting sounding (immediate) or the previous sounding (delayed) just like sensing

  1. it is the result of the single measurement

Correct. This is where ranging differs from sensing.

  1. there is no identification of the report, like setup ID and instance ID to distinguish the report among several saved reports

Measurement instant ID equivalent is carried in the dialog token of the Location Measurement Report (LMR) frame, or the corresponding SAC value in the Secure LTF IE as part of LMR. Therefore, there’s always a ‘measurement instant’ ID.

In the sensing:

  1. more than one type of report exists

Correct

  1. the report may be delayed and reported later in another instance

Correct

3. more than one result may be delivered in one report

Yes, so far we allow more than one delayed measurement results (if responder involved in more than one use cases- more than one setup ID) in the report frame

  1. the result is identified per the setup ID/report type, and the instance ID

Correct

  1. The measurement result may be consumed by the responder

Correct. As far as I understand the result would need to be passed to the SME regardless of it being sent back to the initiator

 

"For the case when the sensing initiator is the sensing transmitter, the reporting of sensing measurement results to the sensing initiator is optional. (motion 60)"

There is the summary of my observation

Ranging: The direct MAC feedback w/o SME involvement is the best suitable presentation of the ranging interaction

Sensing:

It is more like the spectrum management and radio measurement (see 6.3.13 Protocol layer model for spectrum management and radio measurement)

The SME on the responder side is suitable to present the body responsible for the processing of the measurement results to respond with one or more report types.

It enables delivery of the results to the application for further utilization (p.5)

 

Best  regards,

Solomon Trainin

+972547885738

 

From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Monday, February 7, 2022 6:56 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBF] Baseline document for the MLME TTT

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

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

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