Yes, let us use the same timing of the cancelled meeting for tomorrow. I am fine with 10am EDT tomorrow.
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
From: stds-802-11-tgbf@xxxxxxxxxxxxxxxxx <stds-802-11-tgbf@xxxxxxxxxxxxxxxxx>
On Behalf Of ???(Chaoming Luo)
Sent: Monday, April 25, 2022 7:58 PM
To: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: 回复:RE: [STDS-802-11-TGBF]
回复: Feedback on 1934r5
I'm fine to have the ad hoc call as you suggested, thanks!
Thanks Chaoming for including the ‘associated cases’ since so many members have asked for such clarifications!! However, my suggestion is to have yet another call to refine the
slides (if any) and work on the SP texts, since we didn’t get a chance to review them. Additionally, my preference is to refine titles of the essential/detailed sensing capability slides with ‘suggested examples’. Regardless, it is your contribution and I’m
fine with whichever approach you would like to take.
We could meet tomorrow morning 7am PDT time but I need your confirmation and private emails from individuals who want to be involved.
Regards,
Ali
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
According to the last round of offline discussion, I updated it to 1934r6 as posted on mentor. Please do reply
in this email thread if you have any further comments. We might schedule another ad hoc call if needed.
主题： RE: [STDS-802-11-TGBF]
回复: Feedback on 1934r5
Forgot to mention that if non-AP STA wants to initiate an MS setup it can (regardless of being U-STA or S-STA) as it can send MSRQ and get MSRS and establish
the binding. Note that AP is responder in this case and its capabilities is known to STA- no need to do three-way exchange for non-AP STA to be an initiator.
Ali
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
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:
1.
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.
2.
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:
1.
AP sends MS Request (which includes AP’s detailed sensing capabilities)
2.
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.
3.
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
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
|