Thanks. I think an indication of conducted transmit power would address most of the use case, but I agree there might be an additional benefit if the STA is informed of the AP’s ANPI measurement. (Note ANPI would include both thermal noise including NF, and interference during CCA idle).-Thomas
Thanks Abhi, Jarkko and all for the discussion. I have two comments as follows: - Similar to RNR, information advertised by one link that pertains to another link is likely to only be used as a rough estimate by the STA, e.g. so it does not waste time/energy discovering links that clearly will have unusable link quality. If the other link *might* be usable, then the STA can go discover it, and get all the information it needs to accurately estimate the link quality when deciding whether or not to actually activate that link or not. In that sense, I think this subset of information can be kept minimal to avoid increasing overhead. - One significant advantage of the STA knowing the *absolute* transmit power of the AP is that it can also use it to estimate the *uplink* link quality, assuming reciprocality of path loss and antenna gains. [RR] You also would want to know the rx front end NF as it is the other significant contributor to link imbalance. FWIW!This is quite important especially in scenarios with significant tx power imbalance (e.g. if AP power is high but STA power is limited, downlink might look fine but uplink might be unusable). For this, the *conducted* transmit power (not the EIRP) needs to be known - note this is how Transmit Power Used field is defined in Link Measurement Report in baseline, for similar reasons. The definition of the Transmit Power field in TPC Report element in baseline is not very clear, although the tolerance text implies it is an EIRP. For what it’s worth, there is a related definition (targeting similar use case) in section 3.17 and 4.2.7 of [1] (a public document).
Hi Abhi, thank you for the follow up email. The submission11-21/386 seems to say that the transmission power is the only thing that affects to the range of the Beacon frames. I think this is not true. There are many things that affect to the range of the Beacon frame: All these parameters would be good to signal for APs in AP MLD to estimate the range of the affiliated AP. This information may also help to optimize scanning and ensure reliable AP discovery. The group addressed frames transmission parameters may also affect to the range of the AP. Similarly there are many ways to transmit the group frames and these parameters should be signaled for the APs in AP MLD. So just signaling the Beacon frames TX power is not enough information to estimate the range of hte affiliated AP. Other Beacon and group addressed frames transmission parameters are needed too.
I had presented my doc 11-21/386 a few calls ago. During the during the discussion, Jarkko, Guogang and another member suggested that instead of providing the difference in TxPower we should reuse TPC Report element to carry Beacon TxPower information for each AP of the AP MLD. Based on offline discussions, several members prefer to keep the original option (#1) due to its efficiency. Therefore, I would like to run an SP between the two options and go with the majority. Option #1: Provide TxPower difference (if nonzero) in an optional (1-octet) subfield carried in the STA Info field of per-STA profile corresponding to a reported AP Option #2: Provide Txpower information in a (4-octet) TPC Report element corresponding to each AP of the AP MLD. For the reporting AP, the element is carried in the frame body of an ML probe response. For a reported AP, the element is carried in the STA Profile field of the per-STA profile subelement. I’ve attached a copy of the revised doc that shows the changes involved for each option. Could you please review and let me know if you have additional feedback? CAUTION: This email originated from outside of the organization. have you checked the TPC Report element? It seems to be very similar to the new element that you are defining? I am wondering could we use the TPC Report element? Thanks for sharing the doc - sorry for the late respond…. I’ve attach my comments to 11-21/0386r1 – please review them. Thank you to all the members who reviewed doc 386 and provided offline feedback. I have posted r1 of the document to mentor. The revised version incorporates feedback received from several members: Could you please take a look and let me know if you have additional feedback?
<11-21-0386-01-00be-cc34-resolution-for-cid-1038-AK.docx>
<11-21-0386-05-resolution-for-cid-1038.docx>
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
|