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

Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答���: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Discussion on ESS Report element

Hi Guogang

Thanks, please see inline:

On May 11, 2022 at 11:45:27 PM, huangguogang <huangguogang1@xxxxxxxxxx> wrote:

Hi Thomas,

 

Please find my response inline.

 

 

Regards

Guogang Huang

 

发件人: Thomas Derham [mailto:thomas.derham@xxxxxxxxxxxx]
发送时间: 2022年5月12日 1:44
收件人: huangguogang <huangguogang1@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Discussion on ESS Report element

 

Hi Guogang

 

Thanks. You may get some insight on the intention of the original design from slides 3 and 5 of 11-17-0620r0. 

 

Considering the ESS Report element is used to assist roaming, the STA doesn’t care candidate APs are collocated or not.

 

Actually I think it does care. When there are multiple non-colocated BSSs in a planned network, as the STA moves away from its current associated AP (i.e. towards the edge of its current BSS), in general it moves towards another transition candidate AP.

So when the current RSSI falls below a threshold, it becomes more likely there is a better transition candidate available and in general the RSSI of the transition candidate increases.

On the other hand, if we consider two colocated BSSs, as the STA moves away from its current associated AP, it also moves away from the colocated AP(s) too - so when the RSSI falls below a threshold, the RSSI of the colocated APs will be worse too (not better).

[Guogang Huang]I don’t agree with your last sentence. It’s not likely a STA will transition to an AP with worse RSSI. For example, as the STA moves away from its current associated AP, the STA will transition from the associated AP operating on the 5 GHz to an AP operating on the 2.4 GHz. It’s not likely the RSSI of the AP operating on the 2.4 GHz is worse than the RSSI of the collocated AP operating on the 5 GHz.


[Thomas] I should be clearer, I’m talking about the direction of change, not the absolute value. When two APs are colocated, as STA moves so that RSSI on AP1 decreases, the RSSI on AP2 decreases too.
That’s different to the planned dense-AP network topology, where (if AP1 and AP2 are adjacent cells) as RSSI on AP1 decreases, RSSI on AP2 (in general) increases. The ESS Report RSSI value effectively indicates the “crossover point” (at which the RSSIs of the two APs is similar) - if this crossover value is high, it’s worthwhile for the STA to roam more aggressively. I think this is the primary use case for this element.


Now, we could have a scenario where there are colocated APs but they have substantially different coverage (e.g. due to different transmit powers, or different propagation characteristics in each band). So in principle there could be some RSSI that represents the edge of coverage of the lower-coverage AP and might represent a reasonable threshold to transition to the colocated AP that has better coverage.

But this has nothing to do with AP density, so it’s quite a different concept.

I would not necessarily object to usage of this element for such use case - assuming it does not conflict with the mobility roam use case - but if that’s the intent I think some clarification may be needed since it would impact how the STA interprets the RSSI.

[Guogang Huang]If you don’t agree my resolution, could you please provide a document to update this part? Then I can have a whole picture of your resolution and find which resolution is better.


[Thomas] I’m not sure any change is needed at all

 

Could you point out which sentence you are concerned?

 

This sentence has the “shall”: . Otherwise, it shall not initiate a BSS transition if the Planned ESS For MLDs subfield is equal to 0. 

[Guogang Huang]If the current associated AP MLD is alone, then there is no candidate AP to transition. I don’t know why you have concern on this sentence. Could you help me understand what’s your concern?


[Thomas] Sure:
(1) If the situation really is impossible (i.e. there will never be another AP/MLD to transition to), then we don’t need normative language to forbid it because it can never happen.
(2) In practice, I think the situation *is* possible for at least a couple of reasons - [a] beacon frame is unprotected (or, best case, relatively weakly protected with a group key) so can be modified, this can result in DoS attack if STA is mandated to follow the contents, [b] AP might not have knowledge of the topology so it might set the fields inappropriately (also note there’s no “don’t know” value enumerated).


 

Also I am unclear the logic for this “should” recommendation, since the RSSIs advertised on each link are different in general, but this assumes a single threshold is applied to the measured RSSIs on all links irrespective of their txpower and path loss

When the beacon RSSIs of all setup links are below the Recommended BSS Transition RSSI Threshold Within ESS subfield in the ESS Information field of the ESS Report element, respectively, then it should...

[Guogang Huang]My original intention is the Beacon RSSI of each link is below the Recommended BSS Transition RSSI Threshold Within ESS subfield in the ESS Information field of the ESS Report element, then it should… I emphasize the ward “respectively”. Anyway, I will revise the text.


[Thomas] I see, thanks. Maybe “of each link” instead of “of all … links” might make it clearer that each RSSI theshold is individually compared on its respective link.


 

Thanks

Thomas

 

 

On May 11, 2022 at 2:07:43 AM, huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

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.

 

cid:image001.png@01D86556.B7994E20

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.

cid:image002.png@01D86556.B7994E20

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

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