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