The MSQ (Query) is only needed to be sent out by U-STA and not A-STA (associated STA). The purpose of MSQ is to notify AP that I’m available can
be a responder candidate. Note that AP cannot send MSRQ (Request) to a device that is unknown to be able to receive the frame. Again for the associated case the binding continues to use two-frame exchange (MSRQ/MSRS). And for U-STA we’d need three-way exchange
MSQ/MSRQ/MSRS.
Anirud, your three-way exchange doesn’t work for U-STA since MSRQ might not be received.
Ali
From: Sahoo, Anirudha (Fed) <anirudha.sahoo@xxxxxxxx>
Sent: Wednesday, April 20, 2022 10:00 AM
To: luochaoming@xxxxxxxx <000015d97e832564-dmarc-request@xxxxxxxxxxxxxxxxx>; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBF] 回复: Feedback on 1934r5
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Chaoming,
Like Rojan, I also think keeping the session setup and measurement setup (MS) separate is a cleaner design. Perhaps, in your current proposal (slide
7), end of PASN Authentication marks the setting up of sensing session. But AP has exchanged its detailed sensing capabilities by then, which means part of the measurement setup is done by then. So, it is difficult to “demarcate” where sensing session setup
is completed.
I also have the following questions/comments on measurement set up:
- On slide 7, the non-AP STA is sending MS query. It seems little weird that the responder
is asking the initiator to initiate a MS.
- In this contribution, it looks like you do not have the signaling for non-AP STA as the initiator,
right?
I think MS signaling should be started by the initiator, not by the responder. Perhaps, we could think of a three way handshake as follows:
AP as the initiator:
- AP sends MS Request (which includes AP’s detailed sensing capabilities)
- Non-AP STA sends MS Response (with SUCCESS) (which includes its detailed sensing capabilities).
Non-AP STA may reject the MS request by sending a “FAILed” MS response.
- AP sends a MS Confirm to non-AP STA.
thanks and regards
-Anirud
Anirudha (Anirud) Sahoo (He/Him)
https://sites.google.com/view/a-sahoo
National Institute of Standards and Technology
Wireless Networks Division
Communications Technology Lab
100 Bureau Drive, Stop 6730
Gaithersburg, MD 20899
Ph: 301-975-4439
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
|