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

Re: [STDS-802-11-TGBF] Comments on 1321r1 and 1322r1

please see inline comment below 
 
From: Solomon Trainin
Date: 2021-08-31 22:23
To: luochaoming@xxxxxxxx; 罗朝明(Chaoming Luo); STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
CC: Da Silva, Claudio; Chen, Cheng
Subject: RE: Comments on 1321r1 and 1322r1

Hi Chaoming,

About yours [cm1-1]

The example I presented is about that the three initiators and the responder belong to the same BSS

How is it different from “also the same AP” you mentioned in your comment?

 [cm] my intended example is <A, AP, M> for gesture detection application on A,  <C, AP, M> for gesture detection application on C , <C, AP, M> for  instruder detection application on C.

 

Best  regards,

Solomon Trainin

+972547885738

 

From: luochaoming@xxxxxxxx <luochaoming@xxxxxxxx>
Sent: Tuesday, August 31, 2021 4:52 PM
To: 罗朝明(Chaoming Luo) <000015d97e832564-dmarc-request@xxxxxxxx>; Solomon Trainin <strainin@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Cc: Da Silva, Claudio <claudiodasilva@xxxxxx>; Chen, Cheng <cheng.chen@xxxxxxxxx>
Subject: Re: Comments on 1321r1 and 1322r1

 

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

more comments after [cm1-1]

发件人： 罗朝明(Chaoming Luo)

发送时间： 2021-08-31 21:10

主题： Re: Comments on 1321r1 and 1322r1

comments after [cm1]

 

发件人: Solomon Trainin <strainin@xxxxxxxxxxxxxxxx>
发送时间: 2021年8月31日 20:13
收件人: 罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx>
抄送: Da Silva, Claudio <claudiodasilva@xxxxxx>; cheng.chen <cheng.chen@xxxxxxxxx>
主题: RE: Comments on 1321r1 and 1322r1

 

Hi Chaoming,

Please see below indicated with [ST1]

 

Best  regards,

Solomon Trainin

+972547885738

 

From: luochaoming@xxxxxxxx <luochaoming@xxxxxxxx>
Sent: Tuesday, August 31, 2021 1:33 PM
To: Solomon Trainin <strainin@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Cc: Da Silva, Claudio <claudiodasilva@xxxxxx>; cheng.chen <cheng.chen@xxxxxxxxx>
Subject: RE: Comments on 1321r1 and 1322r1

 

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

Hi Solomon,

 

pls see comments inline.

 

BR,

Chaoming

发件人： Solomon Trainin

发送时间： 2021-08-31 17:45

抄送： Da Silva, Claudio

主题： RE: Comments on 1321r1 and 1322r1

Hi Chaoming,

Thank you for your comments

Please see below

 

Best  regards,

Solomon Trainin

+972547885738

 

From: luochaoming@xxxxxxxx <luochaoming@xxxxxxxx>
Sent: Tuesday, August 31, 2021 5:05 AM
To: Solomon Trainin <strainin@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Cc: Da Silva, Claudio <claudio.da.silva@xxxxxxxxx>
Subject: RE: Comments on 1321r1 and 1322r1

 

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

Hi Solomon,

 

As discussed on Aug. 24, my comments as below:

 

1. Please clarify what are the "operational parameters" "may be exchanged" in session setup.

[ST] I think that separate contributions and related discussions are needed to define the parameters. As an example, I may think about the TX and RX antenna configuration and the channel width.

 

2. I think "an optional negotiation process in the sensing setup phase" in motion 17 refers to the "operational parameters" exchanging process (previously in motion 15) in "7.1.2 WLAN sensing session setup".  

   And according to 21/0644r4 slide 7 "The optional negotiation process is named as the Measurement setup in this presentation", I think "7.1.3 WLAN sensing measurement setup" is equal to the "operational parameters" exchanging process.

   So, I think there is only one "optional negotiation process".  But the current 21/1322r2 implies two: one in session setup, and another in measurement setup".  Please help to clarify this.

[ST] The optional negation process belongs to the WLAN sensing measurement setup only. The WLAN sensing session setup is not mentioned as optional

[cm] I believe when the motion 17 runs, the "optional negotiation process" refer to the "operational parameters" exchanging in session setup phase, as stated in 21/0370r1 slide 2.  So I don't agree with your clarification on this point.

[ST1] Certainly, the purpose of the submission is to modify the SFD text (11-21-0504-02-00bf-specification-framework-for-tgbf) to make it consistent and resolve contradictions. I am ready to discuss with you any technical issues you see in that relation.

[cm1] if there are two negotiation processes, then I suggest to identify the difference first, e.g. what are the exact parameters negotiated in each negotiation and why any of the parameters should be in one negotiation but not the other, or why it should be in both processes.

 

3. If there are both session setup/termination and measurement setup/setup termination, how do you expect the user applications (e.g. an application A in a phone,  an application B in another phone,  an application C in a TV)

[ST] The application is associated with the initiator, and each WLAN sensing procedure may have only one initiator, so your example is about three initiators (A, B, and C) that each one maintains its own WLAN sensing procedure.

to manage the session and measurement setup?  E.g., if A and C involve a STA M to do gesture gesture recognition, C involves STA M to do instruder detection,  who and when should setup and terminate the session, who and when should setup and terminate the measurement setup?

[ST] The STA M may participate in several WLAN sensing procedures. In each of the procedures at the session setup, the STA M will get AID/UID per the specific initiator. Each session is independent and may be terminated per the initiator. Each of the initiators separately is responsible to negotiate the measurement setup with the STA M in the sensing procedure it maintains. It may also terminate the measurement setup.

[cm] So this means STA M may maintains several sessions at the same time, then how could STA M differentiate these sessions?  I think STA M will get AID/UID per AP but not per the specific initiator. Or, are you changing the meaning of AID/UID here?

[ST1]  I assume that in your example the initiators (A, B, and C) and the responding STA M belong to the same BSS. Even in this case, each session is uniquely identified as defined “A sensing session is pairwise and is identified by MAC addresses and/or associated AID/UID”. So, the session between the initiator A and the responder STA M is identified by the MAC addresses and the AID/UID of the A and the STA M. The same about the session between B and STA M, and C and STA M. The mentioned MAC addresses and the AID/UID are unique. So, in your example, the STA M uses the MAC address and/or the AID/UID of the initiators A, B, and C to distinguish between the sessions.

[cm1] I think the pairwise session in 21/644 is (AP, non-AP  STA) pair, since the example in 21/644 only shows (AP, non-AP STA) pair.  If now it also has (non-AP STA, non-AP STA) pair, then this implies the previous negotiation in setup/measurement setup also happens between (non-AP STA, non-AP STA) pair?

[cm1-1] I should clarify my example here (A, B, and C) involves STA M, and also the same AP.

 

BR,

Chaoming

 

Date: 2021-08-26 01:53

Subject: RE: Comments on 1321r1 and 1322r1

Hi Claudio,

Thanks for the constructive discussion.

See my answers below, signed by [ST1]

I have not yet received comments from people who I believe intended to provide them

 

Best  regards,

Solomon Trainin

+972547885738

 

From: Claudio Da Silva <claudiodasilva@xxxxxx>
Sent: Wednesday, August 25, 2021 12:15 AM
To: Solomon Trainin <strainin@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: RE: Comments on 1321r1 and 1322r1

 

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

Hi Solomon,

 

Thanks for considering my comments on 132r1/1322r1.  Please find some additional discussion below.

I’d appreciate if you could let TGbf know if/when a new revision of the documents is uploaded.

Once again, thank you.

 

Claudio

 

From: Solomon Trainin <strainin@xxxxxxxxxxxxxxxx>
Sent: Tuesday, August 24, 2021 4:42 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBF] Comments on 1321r1 and 1322r1

 

Hi Claudio

Thank you for your comments

Please see my proposals below

 

 

Best  regards,

Solomon Trainin

+972547885738

 

From: Claudio Da Silva <000015f3cbee3aeb-dmarc-request@xxxxxxxx>
Sent: Tuesday, August 24, 2021 1:03 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBF] Comments on 1321r1 and 1322r1

 

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

Hi Solomon,

 

Please find a few technical comments on your contributions 1321r1 and 1322r1 below.  I would appreciate if you could consider them.

Thanks,

 

Claudio

 

 

My understanding of 1321 and 1322 is that the following changes are being proposed:

·       Modify the current definition of “sensing session” (specifically, “A sensing session is composed of one or more of the following phases: setup phase, measurement phase, reporting phase, and termination phase.”) with “A sensing session is (a) pairwise agreement between a sensing initiator and a sensing responder to participate in the WLAN sensing procedure” (first paragraph of 1322).

·       Add to the SFD the following new definition: “A sensing procedure is composed of one or more of the following: WLAN sensing procedure setup, WLAN sensing measurement instance , and WLAN sensing termination” (second paragraph of 1322).

If my understanding is correct, I would encourage you to modify the text of the SP found in 1321 to clarify the scope of the proposed changes (redefinition + addition). 

[ST] Your understanding of the change is correct. Please note that the SP in document 1321 is devoted to the change of the outline. There are two more SPs in 1322. Do they cover both meanings of the proposed changes?

[CdS] If your goal is to run a SP on the text in 1321 and then both a SP and motion on 1322, I believe we would be OK given that the scope of the changes is clearly defined in 1322.

 

The proposed “WLAN sensing procedure” incorporates both TB and non-TB approaches.  While both approaches have been discussed in TGbf in the past, only the TB approach has been approved by the group so far (motion 25c).  Thus, it is important to call the group’s attention to the fact that a consequence of approving the changes suggested in 1322r1 would be to define a non-TB approach.

[ST] I am not sure I agree that having it in the outline invites people to define the non-TB approach. Although there is no motion to adopt the non-TB approach yet, contributions 990 and 1015 already discuss this approach. I think including it in the outline indicates place and order that the definition of the non-TB approach may require if someone thinks to provide it.    

[CdS] The intent of my comment was to make it clear to the group that, in addition to fixing technical discrepancies, 1321/1322 also add new concepts to be introduced in the SFD.  After today’s (Tuesday’s) discussion on 1322, I believe this fact is now clear.

 

The WLAN sensing procedure defined in 1321 is composed of a number of “elements”/”phases” (slide 5), many of which haven’t been discussed in TGbf yet.  As a result, several sub-sections proposed to be included in the SFD in 1322 are understandably empty.  At the same time, 1322 includes text for both “WLAN sensing measurement setup termination” and ”WLAN sensing session termination phase.”  This topic (termination) is not discussed in 1321 nor in any previous contribution to TGbf.  Could you discuss the proposed addition in 1321 (or in a future contribution)?

[ST] The “Termination phase” already exists in 504. Slide 6 in 1321 illustrates both new proposed terminations. 1322 suggests changes aligned with the overall approach presented in 1321.

[CdS] We had a good number of questions in today’s 11bf call on this exact topic.  I guess this proves the point I tried to previously make.  Personally, I would leave these additions to a future contribution.

[ST1] I still try to provide and agree on the whole picture. I plan to change the text to make it completely clear and resolve comments if they arrive. I want to think more if the separation of this part does not harm the entire picture 

 

So that 1321 and 1322 match, “WLAN sensing termination” (defined in 1322) must be defined to include/be composed of “WLAN sensing measurement setup termination” and “WLAN sensing session termination” (defined in 1321).  (This is similar to what is proposed for the setup: “The WLAN sensing procedure setup includes the WLAN sensing session setup and the WLAN sensing measurement setup as defined below (7.1.2, 7.1.3)”.)

[ST] It is fine with me. Do you agree to change the sentence in 1322r1 like ” WLAN sensing termination includes the sensing session termination and the measurement setup termination may be terminated as defined in 7.1.5 and 7.1.5a respectively.”?

 

[CdS] Now we have a total of 3 setup-related and 3 termination-related definitions:

·       WLAN sensing procedure setup, WLAN sensing session setup, WLAN sensing measurement setup

·       WLAN sensing termination, sensing session termination, measurement setup termination

To simplify the text and avoid confusion, I would prefer to not define “WLAN sensing procedure setup” and “WLAN sensing termination.”  We could, for example, modify the proposed text as follows:

 

A sensing procedure is composed of one or more of the following: WLAN sensing procedure setup, WLAN sensing session setup, WLAN sensing measurement setup, WLAN sensing measurement instance , and WLAN sensing termination WLAN sensing measurement termination, and WLAN sensing session termination (Motion 15, 20/1851r4).

The WLAN sensing procedure setup includes the WLAN sensing session setup and the WLAN sensing measurement setup as are defined below (7.1.2, 7.1.3)

 

If this doesn’t work, I’m OK with your suggestion above.

[ST1] Yes, I tend to agree that “WLAN sensing procedure setup” and “WLAN sensing termination” are not needed. I am fine with the change

 

On page 2 of 1322, we have “A sensing session is (a) pairwise agreement between a sensing initiator and a sensing responder to participate in the WLAN sensing procedure.”  Given that the text defines that “a sensing session is … agreement between a sensing initiator and a sensing responder…”, is the word “pairwise” necessary here?  (Please note that “pairwise” is defined in 802.11-202, page 167, as a term “used to refer to a type of encryption key hierarchy pertaining to keys shared by only two entities.”)  It may be worth to modify “A sensing session is pairwise and is identified by MAC addresses and/or associated AID/UID” as well (delete “is pairwise and” is OK given that this is already defined in the previous statement).

[ST] Would it be OK with you the following that moves one more sentence to the definition?

A sensing session is an instance of a sensing procedure with associated operational parameters of that instance pairwise agreement between a sensing initiator and a sensing responder to participate in the WLAN sensing procedure. (Motion 8, 20/1849r4). A sensing session is pairwise and is identified by MAC addresses and/or associated AID/UID (Motion 23, 21/0644r4).

 

 

[CdS] After I found out that pairwise is defined in 802.11-2020 (see screen caption below), and that the term relates to “a type of encryption key hierarchy”, I would avoid using the term altogether.  At least for me, “agreement between a sensing initiator and a sensing responder” makes it very clear that sensing session is “pairwise.”

[ST1] Thank you for pointing me to the definition. The definition is clear, and I think that the way I use, fits it. I believe the indication of how it is used does not limit to use it in different cases. BTW I can indicate few places in the spec where the use is not about the key hierarchy. I would prefer to keep it as is for now. I think that it helps people to pay attention to the meaning of the session, and each time I speak about the session, I understand from the questions that the meaning of it is still not clear to many people.

 


 

In 1322, the text “NDP can be used for the channel measurement (e.g. CSI)…” is suggested to be moved under “NDPA sounding phase.”  Should it also be added to “TF sounding phase”?

[ST] Yes, I agree it is relevant for both, and I am OK to add it to the “ TF sounding phase”

 

[CdS]  Yes, I think we should.

 

In 1322, the sentence “A sensing session may be comprised of multiple burst instances” is suggested to be replaced with “A WLAN sensing measurement instance may be comprised of multiple phases”.  Is this the intent of the original SFD text?

[ST] Neither burst nor burst instance is defined. I hope that I fairly interpret the intention of the author. I expect to get more inputs while presenting.

 

[CdS] This was also discussed in today’s meeting. I trust you will work with Dongguk on it.

[ST1] It is Sang's motion 14. We started to discuss it in the last .11bf meeting.  I expect him to provide more considerations and plan to have more discussion.

 

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

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