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

Re: [STDS-802-11-TGBF] Discusssion for the Sensing Trigger frame

 

Hi All,

 

Thanks a lot for your feedback and Discussion.

 

Regarding the inclusion of ID information in the sensing Trigger frame, by reflecting on the below discussion, since this document includes the description for three sensing Trigger frame variants, I think that we don’t need to add the text related to ID information. and it is better to avoid adding TBD. However, I always welcome comments from you to discuss this issue.

And, I will keep the use of B4 to indicate the sensing Trigger frame by considering the feedback received from other members.

 

Based on the feedback received from members, I will update the CR document, and then, I will share the updated document with you.

 

Best regards,

Dongguk.

From: Das, Dibakar [mailto:dibakar.das@xxxxxxxxx]
Sent: Tuesday, September 13, 2022 4:58 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBF] Discusssion for the Sensing Trigger frame

 

Sorry for jumping in late to this discussion. I also prefer having B4 to distinguish between ranging/sensing. Also, based on the discussion below, tend to think MSID may indeed not be needed in the TFs.

 

 

 

We could add it to the Report Trigger frame although it is conceivable that received reports are sent to the application (locally or via SBP responder) in a bundle so that application would be able to decipher and not use the ‘invalid reports’.  There could also be a case where STA receives NDPA/NDP (new sound) but didn’t receive the Report Trigger frame correctly hence not even provide the report. Again, at the end the application receives the ‘bundle’ and decipher the missing/invalid ones and use the available ones to make decisions. Otherwise the AP/Initiator would need to manipulate/create responder’s report to help the application, which it could do on its own if sent in an ordered bundle (sort of your report ID concept).

 

 

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

There may be some error case or corner case, e.g., a STA which is good in TF sounding phase, but fail （let's say due to a blink of interference）to receive NDPA and NDP, then in reporting phase with a ’invalid report’ how does the STA know what’s the instance ID value it should set？

Chaoming, it is not just report it also needs to be included in the NDPA frame as well as R2R Trigger frame. Essentially it is added where it makes sense!

 

 

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

Just as discussed in the call, the point is：the current text, as I mentioned in the mail, does not limit the use of instance ID to the identification of the report, it’s should be used in the whole instance. 

If we want to limit it to report, then the  text mentioned should be modified.

Chaoming, except R2R case I don’t really see any reason to convey MS ID or Instance ID in the trigger frames as the responder is simply slaved to the AP and does what AP/Initiator asks for hence the sequence is managed by itself, however it needs to tag the measurement result (SR2SI) with corresponding MSID + Instance ID and possibly responder and its own AIDs so that application can make sense out of it.

 

Do we really need anything else. In the NDPA case we need MSID+ Instance ID because the measurement reported by the responder needs to include these info for the application. Again, AP that is a coordinator and manages the parameters of SI2SR NDP transmission associated with the appropriate MSID + Instance ID

 

Let me know if we need to discuss it further

 

Regards,

Ali

 

 

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

Hi Dongguk,

 

Thanks for your reply. Let me clarify my points:

1. In D0.2, “The Measurement Instance ID may be used to identify the sensing measurement instance that has the same

tuple <Sensing Initiator’s MAC address, Measurement Setup ID>”. Based on that, from initiator’s view, the initiator allocates instance ID values by itself, so no problem for it to identify an instance. However, from any of the responders’ view, how and when does it get the instance ID values allocated by the initiator?

2. For TF sounding, the polling phase may not be there, e.g., all responders are not assigned to be polled.

   For NDPA sounding, the reporting phase may not be there, e.g., the report is not required (e.g., report via OOB methods).

 

BR,

Chaoming

 

 

 

Hi Chaoming,

 

Thanks for your comments.

I tried to answer your question to help your understanding..

1. I don't know if you remember, but I had considered those Two ID information in DCN 22/457r1. when I presented this contribution, I remembered that I had received the comments that the sensing Trigger frame did not need to include that information for the following reason.

A.     Regarding the polling, In my thinking after finishing the measurement setup between the sensing initiator and sensing responders, the sensing initiator has known which STA can participate in this sensing measurement instance. and, the initiator sends the polling frame for checking if this STA can participate or not before starting of sensing measurement. Like this, polling is just used to check the status of STA if it can participate or not, ID information does not need to be included in the sensing polling trigger frame.

B.      In TF sounding phase, Trigger frame is used to solicit the NDP transmission from the sensing receiver. in this phase, AP performs the measurements by using the received NDPs, those ID inform does not need.

C.      regarding the reporting, we can consider the various reporting cases. and for support of various types of reporting, we can consider the define the various types of reporting trigger frames. in my personal opinion, as will be discussed, some types may require ID information. let’s listen to others’ opinions on that.

2. Regarding the composition of the TB sensing measurement instance, we need further discussion. however, in my thinking, I disagreed that TB sensing measurement consists of only TF sounding phase or only NDPA sounding with the  following reasons. First, if TF sounding phase is considered, the STAs participating in the TF sounding phase should perform the polling phase to check if it is possible or not. second, if NDPA sounding phase is considered, it should be accompanied by reporting phase for the transmission of feedback. That is why I disagreed with your opinion that only TF sounding phase or NDPA sounding including is contained in the TB sensing measurement instance.  

 

Best regards,

Dongguk.

 

 

Hi Dongguk,

 

Additionally, I don’t quite understand why measurement setup ID and measurement instance ID are not included in the triggers, hope you can elaborate more about it, thanks!

IMHO, for TF Poll, TF Sounding, and NDPA, all these three frames shall carry MS ID and measurement instance ID, because a TB instance may contain only polling phase,  or only TF sounding phase, or only NDPA sounding phase.  The initiator and the responder shall make sure they’re using the same MS parameters and shall make sure they are synchronized to use the same instance ID to identify each measurement instance of the same MS.

 

BR,

Chaoming

 

 

Hi Dongguk,

 

I tend to support Ali’s idea to use reserved values of  B0-B3 to indicate sensing trigger frames. And if we go this way, I don’t see any needs to additionally use the B4 to indicate sensing.

 

BR,

Chaoming

 

 

 

Hi Ali,

 

Thanks for your suggestion.

 

To avoid misunderstanding or remove the ambiguity according to a value of the Trigger Subtype field in the Trigger dependent common info subfield, I think that reserved values (i.e., it was not used in 11az) can be assigned to the variant of the sensing Trigger frame.

However, as you know we considered the reuse of the ranging Trigger frame format for the sensing trigger frame. since we inherit the ranging frame format for the sensing trigger frame format, by using the value of this subfield, STA can recognize the variant of the trigger frame which was already indicated by using the Trigger type field. Thus, I think that it needs the indication whether it is a ranging trigger or a sensing Trigger, and for that using B4 is a very simple and clear way without additional ambiguity.

So, even though we assign the reserved value which is not used in the ranging Trigger frame for the variant of sensing Trigger frame as suggested by Ali, I think that the use of B4 to indicate the type of Trigger frame is still useful and helpful for a clear distinction between two Trigger frame.

 

Best regards,

Dongguk.

 

 

Gents,

 

Does it make sense to change the table to indicate the subtypes for Poll, Sounding and Report as 8, 9, 10  and keep B4 as reserved in case we need it for something else?

 

The table would look like below. Of course we could still use B4 for sensing?

 

B0-B2

Ranging/Sensing

Trigger Subvariant

B3

Ranging/Sensing

0

Poll

0

Ranging

1

Sounding

2

Secure Sounding

3

Report

4

Passive Sounding

5-7

Reserved

8

Poll

1

Sensing

9

SR2I Sounding

10

Basic Report

11

SR2SR Sounding

12

Threshold Report

13-15

Reserved

 

 

 

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

 

Dear All,

 

I hope you had a nice holiday.

 

I knew that some members would like to discuss this topic by scheduling additional meetings. However, since we have scheduled many CCs for the discussion of other topics this week, it is hard to schedule another CC for this discussion for the sensing Trigger frame. in addition, the 802.11 Interim sessions are scheduled for next week. 

Thus, first of all, I would like to discuss the sensing Trigger topic by using the email discussion to gather opinions for other members.

I revised the CR document for the sensing Trigger frame based on the Comments received during the last CC.

For the indication of this modification, I add the memo in the attached document and add also some discussion points using the memo.

Attached, Please take look at it. I look forward to the good comments from you.

 

Best regards,

Dongguk.

 

 

 

________________________________________________________________________________________

Dongguk Lim

Chief Technology Officer IoT Connectivity Standard Task/Professional

LG Electronics Inc

19, Yangjae-daero 11-gil, Seocho-gu, Seoul, Korea

M.82-10-8996-4690  E.dongguk.lim@xxxxxxx

___________________________________________________________________

 

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

OPPO

 

本电子邮件及其附件含有OPPO公司的保密信息，仅限于邮件指明的收件人使用（包含个人及群组）。禁止任何人在未经授权的情况下以任何形式使用。如果您错收了本邮件，请立即以电子邮件通知发件人并删除本邮件及其附件。

This e-mail and its attachments contain confidential information from OPPO, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

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