Hi,
Seems to be a misunderstanding.
Ali suggests 7am PDT, so 10 am not 10 pm ET.
This is a timeslot that works for all. The other one is 2-3 am Europe.
-Leif
From:
Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Date: Thursday, 21 April 2022 at 03:50
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBF] 回复:RE: [STDS-802-11-TGBF]
回复: Feedback on 1934r5
Thanks Ali for scheduling, but since the Thursday 11bf call on 21 Apr has been cancelled, could we use that slot instead? Friday 10pm ET will be Saturday morning
for us in Asia.
From:
罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx>
Sent: Thursday, April 21, 2022 8:22 AM
To: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: 回复:RE: [STDS-802-11-TGBF]
回复: Feedback on 1934r5
Thanks very much Ali, I'm ok for the call and appreciate your scheduling.
My suggestion is to have
yet another call so that everyone who is interested (please participate in the call in order to avoid similar discussion) can get up to speed as to the reasons for MS Query frame. Chaoming, if you’re
okay with it (please reply to this email if you do) I can schedule a call for this coming Friday morning 7am PDT time.
Of course, if need be we can refine Chaoming’s slides as to remove ambiguity…
Regards,
Ali
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
The purpose of the MS Query frame is: 1). notify the AP that the U-STA is active and ready to
receive MS Request; 2). exchange sensing capabilities when establishing the sensing session.
For the above purpose 1), anyway a new frame needs to be introduced, as MS Query here, and also
the new exchange "MS Query, MS Request, MS Resonse".
Now that MS Query is introduced, we could utilize the frame and exchange to establish the sensing
session.
IMHO, the MS Query is designed to be uplink only.
BTW, the "a separate pair of frames for session setup" is the option1 in my r4, and during the
last round of offline discussion people agreed on option2 which is the current r5, I think Rajat has joined that offline discussion.
主题： RE: [STDS-802-11-TGBF]
回复: Feedback on 1934r5
Hi Chaoming and all,
I also had similar questions a Mike, what is the motivation in replacing a two way frame exchange with a single Measurement Query? Are we
trying to save the overhead of the session setup response? I don’t see why it has to be done, also seems you are also proposing the Measurement Setup Request frame
(from the AP) in response to a Measurement Query frame to be an implicit acknowledgement from the AP to setup the sensing session. In my opinion, a separate pair of frames for session setup (per the original intention) is much cleaner, even if the frames don’t
negotiate any sensing attributes, it can be explicit acknowledgement from both parties to proceed with sensing operations. This seems to be getting unnecessarily complicated in my humble opinion.
Btw, in your slides the Measurement Query seems to be always sent in the uplink while the Measurement Setup Request in the DL? Surely it can
be bi-directional right?
Essentially, we have defined session setup as primarily a capability exchange phase thus not need to be
‘protected’. Sensing measurement setup is when parameters of sensing are
assigned and there’s binding between peers to begin measurement exchange hence it would need to be protected.
For unassociated case, since MS query happens after PASN (as client knows PMF is required) it is able to benefit from PMF and protect client’s
sensing capabilities as well as the fact that client has initiated a request for measurement setup exchange.
Ali
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Correct. MS Request/Response after the SA is complete allows the setup between the Sensing Responder and Sensing Initiator to be protected.
Anything exchanged prior to SA establishment cannot be trusted in a secure environment.
It is not clear to me sharing sensing capabilities sent in Beacon, Probe Response and potentially in Association frame exchanges result in
any security compromise. However, Authentication after Association can protect MS Request/Response in order to protect the sensing parameter assignments plus the knowledge of the measurement exchange occurrences.
Ali
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Ali,
The association request/response is not protected so I don't believe that is sufficient to establish a sensing session, particularly when
security is required. Something needs to happen once the SA is in place.
Gents, for the association case when device has obtained AID it has established session because it exchanged its sensing capabilities during
the association frame exchange hence ready to be used for measurement setup exchange. Use of PMF or PASN is only needed when security is required.
Ali
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
I think we have discussion in your "22/0401r3" about whether sensing requires RSN with PMF, I don't understand why PMF has nothing to do with
sensing.
For additional authorization specific for sensing measurements, I don't see any consensus for it up to now, and I'm not proposing it.
HI Chaoming,
PMF is just a feature that is negotiated during security establishment that allows management frames to be protected. Again, it has nothing
to do with sensing and in my opinion, cannot be assumed to provide authorization for sensing measurements. Either you need another sensing setup exchange to provide authorization or you need to add sensing authorization to the 4-way handshake.
IMHO sensing may require the feature of protection of management frame which depends on PTK, that's the reason I say sensing session is established
after the 4-way handshake for associated STAs.
Hi Chaoming,
For Claudio's information, the 4-way handshake is a protocol exchange between a STA and an AP to derive a PTK.
Also I'd like to understand the intention here, because I don't believe completion of the 4-way handshake can be used to assume anything with
respect to sensing - unless there is a plan to include sensing authorization information in the 4-way handshake.
I'm fine to list the frames used in 4-way handshake, but I guess people may argue that it's already in baseline and do not need SP for it,
anyway I'll add it and see whether there are other comments.
I'll make those four roles as TBD, as Cheng also suggest further discussion for mandatory roles.
Hi Chaoming,
I’m
just asking you to list the frames that make up the four-way handshake ?
to avoid ambiguity.
Yes, as a group, we will have to define a minimum feature set for 11bf.
Claudio
1. '4-way handshake' is a procedure already in the baseline, we're not adding any frame into the procedure. We just utilize the state established by the 4-way handshake procedure.
2. I'm open if the group wants to define a minimum set of mandatory roles, let's more opinions on this point.
Hi Chaoming,
Two points:
-
We must define which frames are sent as part of the 4-way handshake.
-
We can’t make all sensing roles to be optional first, and then define a minimum feature set. It won’t work. I suggest you delete the
proposed initiator/responder/transmitter/receiver capabilities from slide 6. Defining the minimum feature set will require discussion.
Claudio
Thanks very much for your constructive comments! Please see my reply inline. And please let me know if you have further comments, thanks again!
Subject: RE: Feedback on 1934r5
Sorry, my last email has an error:
For example, define that support of the sensing
receiver responder role is mandatory for 11bf capable STAs.
Claudio
Chaoming,
Thanks for all the work you have done on the session setup. I appreciate it.
Find below a few suggestions and questions on the SPs found in 1934r5.
Thank you for all your effort,
Claudio
・
Because SP3 describes the overall sensing session setup procedure, my suggestion is to begin with it (that is, make it SP1).
・
[cm] I did make the SP3 as SP1 during the previous offline discussion, but people think it's better to SP for the MS Query related sequences first, and I tend to agree
that it's a simpler way to push forward.
o
The
“4-way HS”
for the associated case must be defined.
o
[cm] I'll correct the term as "4-way handshake", which is already in clause 3.2 and 12.7.6 of the baseline.
o
“For an unassociated STA, after PASN, if there is,
an exchange of MS Query….”
What does “if there is”
refer to: PASN or “an exchange of MS Query…”?
o
[cm] it does refer to PASN. Would it be better to rewording as "For an unassociated STA, after PASN if PASN is used, an exchange of MS Query…"?
o
I do not believe the figures in slides 7, 8, 9…
should be included in the draft. (If you would like to do so, you will need to reformat them.) Thus, my suggestion is that we don’t
add them in the SFD. If there is any normative behavior defined in them that you would like to cover, please write text instead.
o
[cm] I'm fine with not adding them in the SFD. My intention was to make it easier to understand the procedure.
・
Propose the edits below (in blue) to (current) SP1. (Propose to make this SP2.)
o
The intend of the last sentence of this SP is not clear to me (“The
polling TF within…”).
o
[cm] The intention of "The polling TF within…"
is to describe the cases in slide 10 and 12, which are also related to when and how to use the MS Query frame.
・
I do not agree with some of the sensing capabilities defined in slide 6:
o
Can a STA be
“11bf capable”
if it does not support the roles of sensing initiator nor of sensing responder? We must define a minimum feature set for a STA to be
“11bf capable.”
For example, define that support of the sensing receiver role is mandatory for 11bf capable STAs.
o
[cm] My thinking is we may write a normative text such as "if a STA is sensing capable then it shall support at least one of the roles of sensing initiator and/or sensing
responder". IMHO, "support of the sensing receiver responder role is mandatory for sensing capable STAs" appears a little bit strong, because there may be cases a STA only works as sensing initiator ("neither a sensing transmitter nor a sensing receiver"
as in D0.01).
o
“Support of reporting”:
Does this refer to the ability of a STA to send a Sensing Measurement Report frame or report measurements up to the application (same STA)? This must be defined.
o
[cm] Appologize for the confusion. I should have put a note there "refer to motion 60 for the exact meaning of optional reporting. "
Proposed changes to SP1:
[cm] Thanks for the refinement, I'll take it.
Do you agree to add the following into 11bf SFD?
・
An unassociated STA (denoted as U-STA) transmits the measurement setup (denoted as MS) Query frame to solicit an MS Request frame from an AP.
o
The MS Query frame may contain the detailed sensing capabilities of the U-STA.
・
Upon receiving an MS Query frame, the AP responds with an MS Request frame to the U-STA.
o
The MS Request frame contains the UID assigned to the U-STA.
o
The MS Request frame contains one bit to inform the U-STA to comeback before session timeout expires to solicit an MS Request frame.
・
The AP can also send a MS Termination frame to the U-STA, which contains one bit indicating termination of the sensing session.
・
The Polling TF within a measurement instance contains one bit to inform the U-STA to transmit an MS Query frame outside the measurement instance.
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公司的保密信息，仅限于邮件指明的收件人使用（包含个人及群组）。禁止任何人在未经授权的情况下以任何形式使用。如果您错收了本邮件，请立即以电子邮件通知发件人并删除本邮件及其附件。
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
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
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
|