Re: [STDS-802-11-TGBA] Questions and comments on doc. 11-20-0756r0.

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

I had a typo in my previous email, I meant RSSI is described in Clause 30 (instead of 27).

Best regards,

Xiaofei Clement Wang

Principal Engineer | InterDigital

T: (631) 622.4028

From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** <STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx> On Behalf Of Xiaofei Wang
Sent: Monday, July 6, 2020 10:48
To: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBA] Questions and comments on doc. 11-20-0756r0.

Thanks Rojan and Yunsong.

Hi Yunsong,

Thanks for the comments. I used the same way RSSI is described in Clause 27. Po-Kai has suggested to add a reference to the table in Clause 27. I will upload a r1 soon, which hopefully can address some part of the issues.

I assume that the power density is similar when transmitting WUR signals to that when transmitting regular signals, since the purpose of 11ba is to reuse the OFDMA transceiver to transmit the WUR beacon. Are you aware of any cases in which an AP wants to use a different power density? In addition, I think this parameter just provide the capability to enable the SME to make smart selections. But if it is up to the SME to want to probe on the discovery channel even with a lower RSSI if it chooses to do so.

Best regards,

Xiaofei Clement Wang

Principal Engineer | InterDigital

T: (631) 622.4028

E: Xiaofei.wang@xxxxxxxxxxxxxxxx

From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** <STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx> On Behalf Of Rojan Chitrakar
Sent: Monday, July 6, 2020 03:17
To: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBA] Questions and comments on doc. 11-20-0756r0.

Hi Yunsong,

Since the RSSI values are being processed by the same WUR STA, relative values should work fine right? After all the WUR STA is only comparing the relative RSSIs of different WUR Discovery frames, it doesn’t really need to know the absolute values. Anyway, if the PHY only provides relative values, there is no way for the MAC to report anything else.

In my opinion, as you mentioned in your 3^rd point too, the real issue is how reliable the relative RSSI values will be to compare WUR APs, if different WUR APs use different TX Powers to transmit the WUR Discovery frames.

Just my 2 cents.

Regards,

Rojan

From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** <STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx> On Behalf Of Yunsong Yang
Sent: Monday, July 6, 2020 2:54 PM
To: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBA] Questions and comments on doc. 11-20-0756r0.

Hi Po-kai,

Thank you for sharing your thoughts. I noticed that RSSI in RXVECTOR is conveyed through PHY-SAP, which is between PHY and MAC sublayers. As PHY and MAC sublayers are always implemented in the same chipset, the definition of RSSI in Clause 17, which you quoted, would result in no interoperability issue but give a lot of freedom to implementations. However, for CIDs 7093 and 7094, the RSSI is to be added to MLME-SAP primitives, which is conveyed between MLME and SME. If the RSSI in the proposed MLME-SAP primitives is loosely defined in the same manner as in Clause 17, it might be OK for fullMAC devices. But for softMAC devices, the host CPU and wi-fi chipset may not have a common interpretation of the RSSI parameter. Then, the usefulness of adding this RSSI (as a threshold or a reported value) may be greatly compromised if the host CPU and the wi-fi chipset have different interpretations of what the RSSI value means. Don't you think so?

Thanks.

Yunsong

On Sun, Jul 5, 2020 at 8:58 PM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:

Hi Yunsong,

              I can try to provide my understanding of your question 2.

              In the current RSSI parameter in RXVECTOR, it is mentioned that the RSSI is used in a relative manner as a result, there is no unit for this parameter.

              Using the RSSI parameter as a relative manner has been the default behavior of the baseline (shown below and similar description for HT, VHT , and HE), and I assume that following this practice is ok if we want to have some RSSI feedback.

Best,

Po-Kai

From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** <STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx> On Behalf Of Yunsong Yang
Sent: Sunday, July 05, 2020 3:22 PM
To: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBA] Questions and comments on doc. 11-20-0756r0.

Hi Xiaofei,

Thank you for preparing doc. 11-20-0756r0. I have some questions and comments. Since tomorrow is the last teleconference call of TGba before the July plenary e-meeting and there is only one session for TGba scheduled during the July plenary e-meeting, I would like to get my questions and comments out early to you so that you have sufficient time to consider them.

1. On CID 7093, the commenter proposes to add RSSI threshold as a parameter in .request primitive. You propose to add it in .confirm primitive. Could you please check whether that is the change that you intend to make?

2. On both CIDs, what is the unit for the proposed RSSI parameter? E.g., dBm or mW, and in what step size? And depending on the unit, you may want to fine-tune the value in the valid range column, e.g., if in dBm, RSSI should be mostly a negative value, right?

3. As a general comment to the issue raised by the commenter of both CIDs, are we assuming that all APs are transmitting WUR Discovery frame at the same power density so that the RSSI measured on the narrow-band WUR Discovery frame truly reveals the best AP? Shouldn't AP selection be based on wideband signal?

Thanks.

Best regards,

Yunsong Yang

To unsubscribe from the STDS-802-11-TGBA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBA&A=1

To unsubscribe from the STDS-802-11-TGBA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBA&A=1