Hi Thomas,
Thanks for your discussion. Please find my response inline.
Regards
Guogang Huang
发件人: Thomas Derham [mailto:thomas.derham@xxxxxxxxxxxx]
发送时间: 2022年5月11日
1:11
收件人: huangguogang <huangguogang1@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Discussion on ESS Report element
Hi Guogang
Thanks for the continued discussion.
I believe the original intent of the Planned ESS subfield definition
“ESS that is planned with several BSSs” was to describe a network comprising multiple physical APs in different locations - not simply a single physical AP operating multiple bands.
[Guogang Huang]I don’t think the Planned ESS subfield is to describe a network comprising physical APs in different location. Considering the ESS
Report element is used to assist roaming, the STA doesn’t care candidate APs are collocated or not.
If we were to clarify the current language along these lines, an MLD AP would not necessarily need to set this bit to 1, and I think your issue would be resolved.
[Guogang Huang] If the Planned Of ESS subfield is set to 0, then the legacy STA will ignore the following subfields (i.e. Edge Of ESS and Recommended
RSSI Threshold) by mistake.
That said, even if we take a literal reading of this text (i.e. assume the field should be set to 1 if there is
any other BSS in the ESS that overlaps the coverage area of the BSS advertising this IE - even if that BSS is colocated), I see little value in supporting an indication that there are no other APs (that are not part of that MLD) overlapping coverage
of the reporting AP MLD. In such cases where the MLD is alone, it would simply not send the IE at all.
[Guogang Huang]Considering to assist the legacy STA’s roaming, the AP MLD should advertise the ESS Report element even if the AP MLD is alone.
The scenarios where the MLD AP does have overlapping BSSs is already covered by the baseline definition and RSSI recommendation.
[Guogang Huang] The question is how to differentiate the reporting AP MLD is alone or not?
As a separate point, I am very concerned about the normative language you propose in 35.3.25.1 which seems to forbid the STA from transitioning to another BSS based on measured RSSIs and values of this element. (Even
the “shoulds” are too strong in my view).
[Guogang Huang] Could you point out which sentence you are concerned? Then we can keep discussion. In addition, I want to remind you “should” is
already used in the current text.
I am unable to figure out exactly what this requirement is (does the
“Otherwise” refer to case where PlannedESSforMLDs is not 1, or refer to case where RSSIs are all below the threshold, or both?) but either way I do not think it is appropriate.
Thanks
Thomas
On May 9, 2022 at 11:50:07 PM, huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Thomas,
I think you kind of misunderstood me. The introduced Planned Of ESS For MLDs is used to tell the associated non-AP MLD whether there is a neighboring candidate (no matter it is a legacy AP or AP MLD) which the non-AP MLD can transition to.
The introduced Planned Of ESS For MLDs subfield is just a counterpart of the Planned Of ESS subfield. For an AP MLD, the original Planned Of ESS subfield shall be set to 1. Hence, we need to define a new subfield for MLDs.
If you doubt why we need to define a Planned Of ESS For MLDs subfield, I think you also need to doubt why we need to define a Planned Of ESS subfield in 11ax.
Regards
Guogang Huang
发件人: Thomas Derham [mailto:thomas.derham@xxxxxxxxxxxx]
发送时间: 2022年5月10日 7:10
收件人: huangguogang <huangguogang1@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Discussion on ESS Report element
Thanks Guogang
I don’t think it matters to the STA whether the transition candidates are MLD APs, legacy APs, or some mixture of the two. The STA will find out all that information, and make BSS/MLD selection decisions, once it actually performs its scan.
If a STA doesn’t support a given band, then any RSSI recommendation on that band is not relevant for it anyway.
I think the existing/baseline ESS Report is sufficient to handle MLDs. On a given channel, the AP/BSS sets the RSSI recommendation so that, if a STA scanning/operating on that channel receives the beacon/probe with RSSI equal to or lower than the ESS Report RSSI recommendation, there’s a good likelihood that, if the STA were to perform a scan, it would find some other APs/MLDs that might have better link quality. This cannot per a “perfect” recommendation because the ESS Report is broadcast and the AP doesn’t know what bands/channels the STA supports (e.g. the “best” transition candidate might happen to be on a channel/band that the recipient STA does not support). But nevertheless, it’s a good enough rough indication for this use case.
So I don’t think trying to be more accurate/granular specifically for MLDs really brings much benefit here.
Thanks
Thomas
On May 6, 2022 at 7:50:10 PM, huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Thomas,
Thanks for your discussion. The Planned ESS for MLDs subfield can tell the associated non-AP MLD whether there is neighboring AP/AP MLD to which it can transition base on the recommended RSSI threshold.
For the Edge Of ESS for MLDs subfield, If we consider that some non-AP MLD cannot support some band, then it will not probe the info on that link. In this case, the non-AP MLD doesn’t need to probe all links of the AP MLD. That’s why I add this subfield.
Regards
Guogang Huang
发件人: Thomas Derham [mailto:thomas.derham@xxxxxxxxxxxx]
发送时间: 2022年5月4日 2:25
收件人: huangguogang <huangguogang1@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Discussion on ESS Report element
Because the Planned ESS subfield shall be always set to 1 for the legacy STA if the AP MLD has more than one affiliated AP.
Not clear to me why that is a problem… Effectively it just means that the Edge of ESS and Recommended … RSSI Thresholds fields are actually defined (not reserved).
The value of Edge Of ESS For MLDs subfield = the value of the Edge Of ESS subfield of affiliated AP 1∨ the value of the Edge Of ESS subfield of affiliated AP 2∨…∨the value of the Edge Of ESS subfield of affiliated AP n
I’m not sure this complexity is really necessary. If the non-AP MLD is using multiple links, it can derive this value from the existing ESS Reports on each link, without defining new fields.
Thanks
Thomas
On Apr 29, 2022 at 12:28:26 AM, huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi all,
I initiate this thread to discussion 1931r4. I would like to explain the setting of these subfields in the ESS Report element by using two examples.
Since all APs affiliated with the same AP MLD have the same SSID and belong to the same ESS, the existing Planned ESS subfield and Edge Of ESS subfield cannot be used to assist the roaming for the non-AP MLD. Because the Planned ESS subfield shall be always set to 1 for the legacy STA if the AP MLD has more than one affiliated AP.
In the following, I will give two examples to explain the setting of these subfields. In scenario 1, since there is no neighboring AP or AP MLD, the Planned Of ESS For MLDs subfield is set to 0. But for a legacy STA, since it can initiate a BSS transition between AP 1 and AP 2, the Planned Of ESS subfield is set to 1.
Scenario 1: Single AP MLD
In scenario 2, since a non-AP MLD can initiate a BSS transition among AP MLD 1, AP MLD 2 and AP 3, the Planned Of ESS For MLDs subfield is set to 1.
Scenario 2 with non-co-located multiple APs or AP MLDs belonging to the same ESS
When there is at least one affiliated AP that sets the Edge Of ESS subfield to 1, then the Edge of ESS For MLDs shall be set to 1, which can be expressed as the following formula:
The value of Edge Of ESS For MLDs subfield = the value of the Edge Of ESS subfield of affiliated AP 1∨ the value of the Edge Of ESS subfield of affiliated AP 2∨…∨the value of the Edge Of ESS subfield of affiliated AP n
Please reply with your comments.
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
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