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 3rd 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
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