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

Re: [STDS-802-11-TGBE] [CR-MAC] Feedback Requested for resolution to CID 1038



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

On Jun 22, 2021, at 11:38 AM, Dick Roy <dickroy@xxxxxxxxxxxx> wrote:

 
 

From: Thomas Derham [mailto:00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx] 
Sent: Tuesday, June 22, 2021 11:22 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [CR-MAC] Feedback Requested for resolution to CID 1038
 
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).
 
Thanks
Thomas
 
 


On Jun 22, 2021, at 9:55 AM, Jarkko Kneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
 
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:
                        - MCS 
                        - PPDU type
                        - BW
                        
            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. 
 
            Cheers,
            Jarkko 
 


On Jun 21, 2021, at 21:02, Abhishek Patil <appatil@xxxxxxxxxxxxxxxx> wrote:
 
Hi All,
 
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?
 
Regards,
Abhi
 
 
From: Jarkko Kneckt <jkneckt@xxxxxxxxx> 
Sent: Tuesday, May 4, 2021 8:44 PM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx; Arik Klein <arik.klein@xxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBE] [CR-MAC] Feedback Requested for resolution to CID 1038
 
CAUTION: This email originated from outside of the organization.
Hi Abhi,
 
               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? 
 
               Cheers,
               Jarkko 
 
<image002.png>



On May 3, 2021, at 02:08, Arik Klein <arik.klein@xxxxxxxxxx> wrote:
 
Hi Abhi,
 
Thanks for sharing the doc - sorry for the late respond….
I’ve attach my comments to 11-21/0386r1 – please review them.
 
Thanks in advance.
 
Regards,
Arik
 
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx> 
Sent: 
יום ד 31 מרץ 2021 00:32
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] [CR-MAC] Feedback Requested for resolution to CID 1038
 
Hi All,
 
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?
 
Regards,
Abhi
 

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



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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature