Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Adding
one word. 发件人: stds-802-11-tgbf@xxxxxxxxxxxxxxxxx <stds-802-11-tgbf@xxxxxxxxxxxxxxxxx>
代表 周培(Pei Zhou) Hi Anirud, Thank you very much for your suggestions. I agree with you that we have to figure out the use case to terminate a subset of MS is a “common” occurrence or a “rare
occurrence”. For a sensing initiator who has set up multiple MSs (or sensing applications) with sensing responder, it may have many reasons to terminate any MS (or sensing
application). But my confusion is what’s the motivation/reason for a sensing responder (not the sensing initiator) to terminate one MS? In my opinion, a possible motivation is that the sensing responder wants to release some resources for its communication services. But it doesn’t mean the sensing
responder will not participate in any sensing service (i.e., terminate all MSs). It can be a tradeoff between communication resource and sensing resource. Yes, maybe some application vendors in this group can shed some light.
😊 PS: If a STA gets a TXOP to transmit multiple termination frames, why
not
just transmit one aggregated (I mean carry multiple MS IDs) termination frame? It is more efficient. Best regards, Pei 发件人: Sahoo, Anirudha (Fed) <anirudha.sahoo@xxxxxxxx>
I think there are multiple points being discussed here. If we separate them out and discuss “point-wise” we may be able to arrive at
a solution:
1.
Will the use case to terminate a subset of MS be a “common” occurrence or a “rare occurrence”? If we have a clear answer to the above question, then the rest becomes easy. Maybe
some application vendors in this group can shed some light.
2.
Assuming that the answer to (1) is that it is a common occurrence or that we do not have a clear answer, what is the overhead
of implementing Pei’s design vs. sending multiple MS termination? In terms of overhead, there are two aspects:
(a)
Overhead due to frame structure: Perhaps, we can do a “back of the envelope” calculation to compare, let us say, 10 terminations
by the two methods.
(b)
Overhead due to MAC access: Not sure how to quantify this for 10 terminations, but others may have some idea.
PS: For 2(b), a STA does not need to contend the channel 10 times, right? It may get a TXOP in which it can transmit multiple MS termination
frames, right? If yes, we should take this into account while discussing 2(b). 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:
周培(Pei Zhou) <zhoupei1@xxxxxxxx>
Hi Cheng, Thanks for your clarifications. I think we understand each other’s opinion very well. In terms of the overhead comparison between bitmap and multiple termination frames, don’t forget the MAC header of each termination frame and transmitting multiple
termination frames needs to contend the channel for multiple times. Anyway, I am going to put different designs/options together into my contribution, and bring it back again next week. I am open on this design, let’s see the preference of the TGbf members. Thanks again. Best regards, Pei 发件人: Chen, Cheng <cheng.chen@xxxxxxxxx>
Hi Pei, In your example, I think the STA would rather terminate all sensing measurement setups as the low latency traffic is prioritized, so I said maybe a single bit
indicating “terminating all setups” makes sense for me and we should consider adding it in the frame. I don’t believe in that case a STA will only terminate a subset of measurement setups.
Again, my main concern is always on the point that I think the scenarios where we need to terminate a subset of multiple setups is unlikely to happen. Therefore,
I am not at all convinced of the merit of terminating multiple setups exactly at the same time and will not support the proposal to design the frame in this way.
The bitmap you proposed may work. But it will always add overhead to scenarios where we only need to terminate one measurement setup at a time, which I believe
would be the majority in practice (Say, > 95%). So, the question is, if >95% of the time we are only terminating one setup at a time, why do we want to waste 16 bits in 95% of all the termination frames? If you calculate in this way, you will find the added
overhead by sending multiple termination frames claimed in your argument would be trivial compared to your proposal. Best, Cheng From:
周培(Pei Zhou) <zhoupei1@xxxxxxxx>
Hi Cheng, Claudio and Anirud, Thanks again for your detailed explanations. Now, I understand your opinion on over-engineering if we make the termination frame of variable length. But I am thinking what is the motivation of terminating one measurement setup? Is there any difference in the motivation between terminating just one measurement
setup and terminating multiple measurement setups? A possible motivation is that: a STA has established multiple measurement setups, when there comes low-latency traffic or it has low battery, it wants to guarantee
its low-latency traffic first or just keep one or two sensing applications in order to save power. So it decides to terminate some of the established measurement setups in order to release resources (time domain, frequency domain, memory, cache, etc.). By the way, if you are caring about the issue of variable length, I think we can make it fixed length, for example, by indicating multiple measurement setup IDs
with bitmap as shown below. Note: The length of TB/non-TB Measurement Setup ID Bitmap field is fixed but TBD (2^n bits), it is determined by the length of Measurement Setup ID (n
bits). For example, if Measurement Setup ID = 3 bits, then the length of TB/non-TB Measurement Setup ID Bitmap field is 8 bits. Please let me know your opinion, thanks. Best regards, Pei 发件人: Sahoo, Anirudha (Fed) <anirudha.sahoo@xxxxxxxx>
I also agree with Claudio and Cheng that we should keep the termination frame simple (fixed length) and if a STA wants to terminate
multiple setups, it should send multiple termination frames. In the simple fixed length termination frame we can provide a flag (1 bit) to indicate that all setups be terminated. 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 Chen, Cheng Hi Pei, I agree that a given pair of STAs would not need to support 10+ measurement setups. However, it is possible that a STA may set up more than two measurement
setups. If one termination frame can terminate multiple measurement setups, we only need to transmit one termination frame. [Cheng] As I have indicated in the call, in scenarios where a STA has established multiple measurement setups, it is unlikely that the STA need to terminate multiple
setups at the same time. Because these multiple setups correspond to multiple applications, which have different sensing parameters, sensing schedules and timing requirements. I totally do not believe that it will happen frequently that these multiple applications
will need to be terminated exactly at the same time using a single termination frame. If one termination frame only terminates one measurement setup, when there are multiple measurement setups to be terminated in a short time period, the STA has
to contend the channel multiple times to transmit multiple termination frames. It is very inefficient (also introduces high overhead). [Cheng] First of all, as I mentioned above, I do not believe these multiple setups will need to be terminated in a short time period (say, within 1ms) because they
correspond to multiple applications. Secondly, currently the termination frame you design is way more complicated because most of the fields are of variable length due to possibly different number of setups that need to be terminated, therefore both the transmitter
and receiver will need to be designed in a way that are always prepared to send or receive a frame of variable length. Instead, if the termination frame is only targeted for one single setup, the design will be pretty simple and much easier for both the transmitter
and receiver. Moreover, I still don’t understand why one termination frame carries multiple measurement setup IDs is complex and over-engineered. [Cheng] Reason is simple. First, it is extremely unlikely that multiple setups need to be terminated at exactly the same time. Secondly, in order to accommodate multiple
setup termination, the frame has to be designed in a complicated way that the length is variable depending on the number of setups that need to be terminated. Third, I think it makes some sense to design a way to terminate all setups, which could be achieved
as simple as one bit. Except for this one bit to indicate termination of all setups, I don’t believe we need anything more than that. I fully agree with Claudio that the current proposal is over-engineering against extremely rare scenarios in practice and therefore will not support it. Best, Cheng
From:
周培(Pei Zhou) <00001462c7c6c67a-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Claudio, Thanks for your comments. I agree that a given pair of STAs would not need to support 10+ measurement setups. However, it is possible that a STA may set up more than two measurement setups.
If one termination frame can terminate multiple measurement setups, we only need to transmit one termination frame. If one termination frame only terminates one measurement setup, when there are multiple measurement setups to be terminated in a short time period, the STA has
to contend the channel multiple times to transmit multiple termination frames. It is very inefficient (also introduces high overhead). Moreover, I still don’t understand why one termination frame carries multiple measurement setup IDs is complex and over-engineered. Best regards, Pei 发件人: Claudio da Silva <claudiodasilva@xxxxxx>
Hi Pei, Thanks for your contribution. The fact that the group has identified 10+ use cases doesn’t imply that a given pair of STAs would need to support 10+ simultaneous
measurement setups. The conclusion does not logically follow from the argument. As I also mentioned during our last conference call, the overhead of the setup termination process compared to the overall sensing procedure
is minimal. We should not over-engineer it and make it more complex than necessary. Thank you, Claudio From:
周培(Pei Zhou) <00001462c7c6c67a-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Cheng and other members who still have concerns on this contribution, As I explained in the meeting, it is possible that a STA may run many sensing applications. For example, there are at least 10 (sub-7GHz) use cases listed in
doc.: 11-20-1712-02-00bf-wifi-sensing-use-cases, even the same use case may need different attributes/sensing parameters. Thus, there is a possibility that a STA may need more than 10 measurement setups to support different use cases/sensing applications. Considering a practical scenario, if a STA has set up multiple measurement setups (e.g., 4), and it decides to terminate some of these measurement setups (e.g.,
terminate 3 and keep one), it is efficient to use our proposed termination frame format. Because only one termination frame is needed to be transmitted, we don’t have to transmit 3 termination frames. To sum up, I believe termination frame has strong motivation to carry multiple measurement setup IDs. It is a low signaling overhead solution. Please let me know your opinion, thanks. Best regards, Pei 发件人:
周培(Pei Zhou) <> Hi Tony, Based on offline discussion, I made some changes to
22/0626: Updates on measurement setup termination frame. Please help to add the revised version to the queue and I will try to run SP, thanks.
l
11-22/0626r2, Updates on measurement setup termination frame, Pei Zhou (OPPO), 20 min. Best regards, Pei
发件人:
stds-802-11-tgbf@xxxxxxxxxxxxxxxxx <stds-802-11-tgbf@xxxxxxxxxxxxxxxxx>
代表 周培(Pei Zhou) Hi Anirud, Thank you very much for your detailed suggestions. I agree with the fact that it is more flexible if the original “terminate all” in my proposal is changed to “terminate all measurement setup initiated by the transmitter”
and “terminate all measurement setup initiated by the receiver”. However, I don't know what the actual scenario is. Because, terminating all the measurement setups initiated by one STA (transmitter or receiver) doesn’t mean that this STA doesn’t have to participate in subsequent
sensing measurement(s). Best regards, Pei 发件人:
stds-802-11-tgbf@xxxxxxxxxxxxxxxxx <stds-802-11-tgbf@xxxxxxxxxxxxxxxxx>
代表 Sahoo, Anirudha (Fed) With the current frame structure, if a STA, as a transmitter of setup termination msg, wants to terminate all measurement setup ids
initiated by itself (but not the ones initiated by the rcvr), then it has to list all the measurement setup ids. We can make this case more efficient (and make the whole scheme more flexible) by having the “termination control” field as follows: Leftmost 2 bits: 00 : tx measurement setup id list NOT present 01: terminate all measurement setup initiated by the txmitter 10 : tx measurement setup id list present 11 : reserved (not used) Next 2 bits: 00 : rx measurement setup id list NOT present 01: terminate all measurement setup initiated by the rcvr 10 : rx measurement setup id list present 11 : reserved (not used) Rest 4 bits: reserved Thus,
1.
if a STA wants to terminate all sensing measurement setup(s) initiated by both the transmitter and the receiver of the Sensing
Measurement Setup, then the first 4 bits should be “0101”. The frame will be just 1 octet.
2.
If a STA wants to terminate all sensing measurement setup(s) initiated by the transmitter of the Sensing Measurement Setup
and zero measurement setup initiated by the rcvr of the Sensing Measurement Setup then the first 4 bits should be “0100”. The frame will be just 1 octet.
3.
If a STA wants to terminate all sensing measurement setup(s) initiated by the transmitter of the Sensing Measurement Setup
and at least one measurement setup(s) initiated by the rcvr of the Sensing Measurement Setup then the first 4 bits should be “0110”. Then the “number of measurement setup ids set by rx” field should be present followed by “Rx measurement setup id list”.
4.
If a STA wants to terminate at least one measurement setup(s) initiated by the transmitter of the Sensing Measurement Setup
and at least one measurement setup(s) initiated by the rcvr of the Sensing Measurement Setup then the first 4 bits should be “1010”. Then the “number of measurement setup ids set by rx” field and “number of measurement setup ids set by tx” should be present
followed by the respective lists. PS: In the document we should replace “measurement setup ids set by rx” by “measurement set up initiated by the receiver” and
replace “measurement setup ids set by tx” by “measurement set up initiated by the transmitter”. This, in my opinion, will be less
confusing. 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 ??? Hi Ali, I tend to agree with you using the MU frame is more efficient, but for these devices(e.g. 11n devices) not support the MU we may need to think more
about it. Regards Xiandong
发件人: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>
Hi Xiandong, There is no real good reason to introduce protected groupcast frames as it has many complexities including allowing such frames to be used by non-AP STA terminating
NTB sequences from several APs (i.e. non-STA sharing groupcast key with several APs). Additionally, because of allowing unassociated STAs to be included in sensing measurement exchange, such a device is not always available to receive thus requires adding
polling phase. Finally, obtaining Ack for termination frame is very useful and groupcast/broadcast management frames at this point are no-ACK frame unless we introduce additional complexities to deal with it.
Having said that, AP initiator can always transmit MU frames with inclusion of multiple protected unicast frames, in case it is seeking for channel efficiency.
Bottom line, unicast protected management frame seems to be adequate for now. BTW, TB reporting phase includes transmission of sensing trigger report frame to obtain one or more unicast protected management frame and does NOT include groupcast
frame. Regards, Ali From:
董贤东 <dongxiandong@xxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Ali, I think we can explore the groupcast termination frame to terminate one or multiple sensing setup with multiple responders is more efficient, and which
is similar way as reporting phase, but we need to have groupcast key for the termination frame. Regards Xiandong
发件人: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>
Thanks Dibakar, I don’t think we have explored the idea of using single MS Request/Response frame exchange to establish multiple sensing setups as use cases aren’t necessary occur
at the same time. However, we could in case such information is known to the initiator. For that we would need to move the ‘measurement setup ID’ field to the ‘sensing measurement parameter element’ so that we could multiple IEs. Ali From: Das, Dibakar <dibakar.das@xxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi, Regarding grouping multiple session IDs, I think we should follow the same approach for both sensing setup and termination. If we allow negotiating multiple sessions
with one setup request/response frame we can do that for termination as well. Regards, Dibakar From: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>
Hi Pei, Sorry for my comment during the meeting as I heard that you were talking about the use of MAC addresses which took me to the path of frame being sent with broadcast
address requesting termination of setup IDs to many devices!! Now that I understand the intention is to accommodate TB and NTB termination in the same frame between pair of devices, we could add a control byte (which could also contain bits indicating “terminate-all
MS” and possibly ‘terminate session’) where it can also include TB/NTB setup field present bits. I guess TB/NTB is analogous to your Tx/Rx indicator (depending on whether it is from AP or non-AP initiator). Regards, Ali From:
周培(Pei Zhou) <00001462c7c6c67a-dmarc-request@xxxxxxxxxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Xiandong, Please see my comments inline. Best regards, Pei 发件人:
董贤东 <dongxiandong@xxxxxxxxxx>
Hi Pei, Thanks for your clarification, please see my comments inline. Best Regards Xiandong
发件人:
周培(Pei Zhou) <00001462c7c6c67a-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Xiandong, According draft 0.01 (refer to Clause
11.21.18.1 Overview, especially Figure 11-41—Example of a WLAN sensing procedure), AP can initiate TB measurement setup (this setup will keep active before termination), then STA can also initiate non-TB measurement setup before the TB measurement setup
is terminated. That is to say, both TB and non-TB cases are active at the same time period. 【dxd】:
this means that the both cases occur in time order, not simultaneously , note that we have defined delayed report and immediate report in the D0.01, and if the delayed report is used for the TB case, I think that it is better to send two separate frames for
TB and non-TB case, since the inactivity time for the non-TB case is expired, meanwhile the delayed report is not received/transmitted for TB case. [Pei]: Please look at the figure below, if we assume Measurement Setup ID = 1 corresponding to TB case, Measurement Setup ID = 2 corresponding to non-TB case,
then TB and non-TB can occur in the same time period in disordered. There is no limitation that which case is performed before and then followed by another.
In terms of the delayed report, if there is delayed report after the termination frame, we can just discard it. Because if a station decides to send a termination
frame, it usually means the measurement results are enough. By the way, this is not a new issue caused by our contribution. It always exists as a corner case. Since one termination frame can finish two kinds of termination (for TB and non-TB), why we still use a higher overhead solution: send two separate termination
frames? Hope my explanations can address your concerns. Therefore, AP or non-AP STA can initiate measurement setup termination for TB case and/or non-TB case. Best regards, Pei 发件人:
董贤东 <dongxiandong@xxxxxxxxxx>
Hi Pei, I don’t understand what does the sentence “Since both TB and non-TB
cases may overlapping in time” mean, it means the both cases could be occurred simultaneously for the same initiator and responder? Best regards Xiandong 发件人:
周培(Pei Zhou) <00001462c7c6c67a-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Solomon, Thanks for your clarifications and comments. Yes, the case is that the same non-AP STA participates in both TB and non-TB sensing with the same AP. I think your idea is to use two termination frames, one to terminate some measurement setups in TB case and the other to terminate some measurement setups in
non-TB case. Since both TB and non-TB cases may overlapping in time, why we just use one termination frame to terminate measurement setups in both TB and non-TB cases? Best regards, Pei
发件人: Solomon Trainin <strainin@xxxxxxxxxxxxxxxx>
Hi Pei, The presentation introduces overlapping of the MS IDs based on the assumption that both the AP and non-AP allocate the MS ID value. The assumption is wrong for
TB sensing. It may be relevant when observing both TB and non-TB sensing. So, the case is that the same non-AP STA participates in both TB and non-TB sensing with the same AP. So, one solution can be to indicate in the termination frame what it is TB or non-TB
and not to mixt the TB and non-TB in the same termination frame. No need for any TX/RX fields. Best regards, Solomon Trainin +972547885738 From:
周培(Pei Zhou) <00001462c7c6c67a-dmarc-request@xxxxxxxxxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi all, I presented this contribution today. Let me explain a little bit:
1.
Both AP and STA can maintain multiple measurement setups. It is not efficient if we limit one termination frame from only terminating one measurement
setup (ID).
2.
When we terminate multiple measurement setups by one termination frame, we need to indicate who set the measurement setup ID(s).
3.
The method of indicating who set the measurement setup ID(s) is that we use two list (Tx List and Rx List), the “Tx” and “Rx” is the “Transmitter” and
”Receiver” of the termination frame.
4.
Why we don’t use “Initiator List” and “Responder List”? Because both AP and non-AP STA can act as Initiator. “Initiator List” and “Responder List” maybe
misleading to the receiver of the termination frame. I hope my explanations can address some of your concerns. Your comments and suggestions are welcome. Best regards, Pei Zhou 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 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 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 |