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

Re: [STDS-802-11-TGBE] [EXT] Re: [STDS-802-11-TGBE] SP#4 of doc 358



Hi,


Agree with Jarko's comment.  The non-transmitted BSSID  is for the virtual BSS  based on the same PHY .  Therefore if we want to use non-transmitted BSSID  to indicate the BSS of another link, it implies that both links should have the same PHY parameters. Otherwise the non-transmitted BSSID will confuse non-AP MLDs , and existing stations.


Best Regards

Yonggang Fang

ZTE (TX)

Phone 858-883-7984

Original Mail
Sender: JarkkoKneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx>
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>;
Date: 2020/05/13 14:18
Subject: Re: [STDS-802-11-TGBE] [EXT] Re: [STDS-802-11-TGBE] SP#4 of doc 358
Hello,

I wanted to share my 2 cents on SP4. 
I think, the network operator should be able to configure in which links it wants to operate a network. For instance, some quest networks may not need as many links as the business critical networks. Reduced number of networks in a link reduces traffic in the link and improves these BSSs performance. 

I also agree with Liwen, that different links should be able to use different beaconing. For instance, 2.4 and 5 GHz may need to have co-hosted beaconing to make APs discoverable for legacy devices, but 6 GHz can use multi-BSS beaconing. 

Abhi, I would like to propose new wording for SP4:
• Do you support that each AP of an AP MLD is independentlyconfigured to operate as transmitted or non-transmitted BSSID of a multiple BSSID set or as an AP of a co-hosted BSSID set?

Cheers,
Jarkko 

On May 13, 2020, at 2:10 PM, Liwen Chu <liwen.chu@xxxxxxx> wrote:

Hi Ming,
 
In my presentation about multi-BSSID, two options are mentioned. But we prefer that when an AP of an AP MLD in one link has transmitted BSSID, the AP of the AP MLD in another link doesn’t need to have transmitted BSSID.
 
Best Regards,
Liwen
 
From: Pooya Monajemi <00000ef0b9e0aff7-dmarc-request@xxxxxxxxxxxxxxxxx> 
Sent: Wednesday, May 13, 2020 1:57 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [EXT] Re: [STDS-802-11-TGBE] SP#4 of doc 358
 

Caution: EXT Email

Hello, 
Adding two comments below
 
Pooya
  
On Wednesday, May 13, 2020, 08:30:33 AM PDT, Abhishek Patil <appatil@xxxxxxxxxxxxxxxx> wrote:
  

Hi Ming,

 

My responses in-line below in blue:

 

From: Ganming (Ming) <ming.gan@xxxxxxxxxx> 
Sent: Wednesday, May 13, 2020 5:49 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 
答复: [STDS-802-11-TGBE] SP#4 of doc 358

 

CAUTION: This email originated from outside of the organization.

Hello Abhi

 

Thanks for your quick response. I may understand your proposal a little bit better. Please see my further response inline.

 

Best wishes,

Ming Gan

 

发件人: Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx] 
发送时间: 2020513 13:04
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] SP#4 of doc 358

 

 

Hi Ming,

 

>> If an AP in the same AP MLD as the reporting AP  is non-TX BSSID, could we put it into the MLD element in the core frame based on the above first sentence?

Yes

 

>> Is that possible that the AP advertised by the MLA element contained in the nonTxBSSID profile carries MLO information is TXBSSID?

Yes

 

>> Go back to my previous question, could the figure in slide 11 advertise the info of all the APs shown in slide 3 or just partial of them?

All the APs

[Ming] Do you mean all the APs advertised by MLA element in the core frame and MBSSID element which may contain another MLA?

AP: What do you mean by MLA? The MLA IE in core frame and/or MBSSID IE will carry information of the corresponding MLD, any common information that is applicable to all the APs of that MLD and information pertaining to each AP affiliated with that MLD.
  

My question is about complete info of the AP, not the minimum info, so RNR is excluded.

AP: When one of the AP is setup to operate on 6 GHz, the lower band (2.4/5G) will advertise information about that AP via the RNR so we can’t exclude of RNR. Whether the information in MLA IE is complete or partial would depend on the frame and/or scenario. For example, I expect the Beacon in most cases would carry partial information which provides basic information about each AP and its configuration so that a scanning STA can select the right AP for ML association. Further an associated MLO STA can make determination if there is any change to the configuration of another AP of the MLD that is associated with. We have these details in our contribution 356 (and new one to be posted 586). If the channel is lightly loaded, an AP may choose to advertise complete information.

 

In this way, I do not think the advertised APs can contain BSSID-q, BSSID-b and BSSID-c based on you below explanation if the reporting AP is BSSID-x. If it can, please explain it more, thanks.  

AP: the RNR and MLA IEs will provide information of ALL the APs. RNR will have an AP entry for all the co-located APs – not just APs that are part of the MLD to which the reporting AP belongs to. From the figure on slide #3 (of doc 357), let’s say BSSID-y were to be the TxBSSID on link 1, BSSID-q were to be TxBSSID on link 2 and BSSID-a were to the TxBSSID on link 3. On link 1, the beacon from AP-y will contain RNR which would carry information of all the BSSIDs shown in the figure (BSSID-x in the nonTxBSSID profile of MBSSID IE, BSSID-a in RNR (as TxBSSID), BSSID-b in RNR (as nonTxBSSID), BSSID-c in RNR (as nonTxBSSID), BSSID-p in RNR (as TxBSSID), BSSID-q in RNR (as TxBSSID), and BSSID-r in RNR (as nonTxBSSID)). The Beacon from AP-y will also include MLA IE carrying information of MLD 3 and profile for AP-r. The nonTxBSSID profile for BSSID-x will contain MLA IE carrying information of MLD 1 and the profile for AP-p and AP-a. Similar information in Beacon frame transmitted on Link 2 and Link 3 by AP-q and AP-a respectively.

 
PM: Abhi I think Ming is asking is if in AP y's beacon there is an MLA about BSSID-q (for the trimmed-MLD picture below, where link 1 doesn't have MLD2). IMHO, we could make it possible to optionally add but the case is less important.  You cannot associate/setup to MLD 2 on link 1, you need to be in link 2/3, so might as well get the full MLA info on those links. 
 

Co-located APs below means the AP in the same AP MLD. Please correct me if there is something wrong.   

AP: co-located APs is the definition from 11ax.

 

<image001.png>

 

RNR indicates whether an advertised AP is TxBSSID or nonTxBSSID

The MLA IE provides information about which MLD a reported AP belongs to.

MLA IE carried in the core beacon provides information of MLD and co-located APs of the TxBSSID

MLA IE carried in the nonTxBSSID profile provides information of MLD and co-located APs of that nonTxBSSID

The Link ID field provides a binding between an AP entry in RNR and a per-link (or per-AP) profile in the MLA IE

 

>> By the way, even in the limitation case, multiple BSSID set is also per link specific to the clients. It does not change the required SSID type and #, the BSSID # on each link. It just moves their positions on the same link related to the MLD 

 

Could you please elaborate on how it works for the following figure?

[Ming] As I said, we keep the same requirement for multiple BSSID on each link, taking link 2 for an example, if link 2 is configured with <SSID 1, BSSID q> and  <SSID 2, BSSID r>, we keep this requirement, but move  <SSID 1, BSSID q> into MLD 1 in your example.

AP: BSSID-q is affiliated with MLD-2 why is it being moved under MLD1?

Let’s say we have a configuration as follows: 
Enterprise network – AP-a [TxBSSID] (L1) and AP-x [nonTxBSSID] (L3) 

Guest network – AP-q [TxBSSID] (L2) and AP-b [nonTxBSSID] (L3)

Private network – AP-y [TxBSSID] (L3) and AP-r [nonTxBSSID] (L2)

 

Why do you want to move the guest AP under the enterprise MLD?

The guest AP has its own security/SSID configuration and other policies and should stay under the guest MLD.

PM: Ditto, MLD will closely follow network policies and you can't move BSSID from one to the other. In the example above if you moved BSSID q to MLD 1 then you'd create three enterprise BSSID's and removed a guest one. Not the original intention of the design.
 

 

<image002.png>

 

Regards,
Abhi

 

From: Ganming (Ming) <ming.gan@xxxxxxxxxx> 
Sent: Tuesday, May 12, 2020 6:32 PM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 
答复: [STDS-802-11-TGBE] SP#4 of doc 358

 

CAUTION: This email originated from outside of the organization.

Hello Abhi,

 

Follow my question (I do not get a clear answer). Regarding the follows

 

The MLA element in the core frame carries the MLO information for the AP corresponding to the TxBSSID. While the MLA element contained in the nonTxBSSID profile carries MLO information for the AP corresponding to that nonTxBSSID.

 

If an AP in the same AP MLD as the reporting AP  is non-TX BSSID, could we put it into the MLD element in the core frame based on the above first sentence?  Is that possible that the AP advertised by the MLA element contained in the nonTxBSSID profile carries MLO information is TXBSSID?

 

Go back to my previous question, could the figure in slide 11 advertise the info of all the APs shown in slide 3 or just partial of them?

 

By the way, even in the limitation case, multiple BSSID set is also per link specific to the clients. It does not change the required SSID type and #, the BSSID # on each link. It just moves their positions on the same link related to the MLD

 

Best wishes

Ming Gan

 

发件人: Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx] 
发送时间: 2020512 15:06
收件人: Ganming (Ming) <ming.gan@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBE] SP#4 of doc 358

 

 

Hi Ming,

 

Thank you for your comments.

 

>> In my mind, both Limitation and independent cases have almost the same performance on the network, and satisfy the network configuration.

 

There is a difference. Independent operation would mean multiple BSSID set on each link are independently configured and operate independent of conditions on another link. This is what the SP is proposing. In the limiting case, the membership on a link is influenced by the configuration on other link(s).Adjusting the membership of the set on one link based on configuration of other link(s) will have far reaching implications as I pointed out in my previous email. Plus any change to the configuration on one link will have a cascading effect on other links. As a framework, we should avoid this.

 

>> It is similar to the restriction that AP MLD is STR.

 

It is not an apples to apples comparison. Multiple BSSID set is a per-link (legacy) feature independent of the setup on another link. The configuration of the multiple BSSID set for a given link is based on the requirements for that link. STR/n-STR, on the other hand, are MLO specific capabilities of a device.

 

>> it is just to decrease a few unnecessary configuration cases due to limited benefit

 

Could you please elaborate or provide examples for this?

 

>> A question to Abhi, could the figure in slide 11 advertise the info of all the APs shown in slide 3 or just partial of them? Do you consider the coexistence when transmitting Multiple BSSID element? Just double check if we are in the same page.

 

The MLA element in the core frame carries the MLO information for the AP corresponding to the TxBSSID. While the MLA element contained in the nonTxBSSID profile carries MLO information for the AP corresponding to that nonTxBSSID.

 

Regards,
Abhi

 

 

From: Ganming (Ming) <ming.gan@xxxxxxxxxx> 
Sent: Sunday, May 10, 2020 6:01 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 
答复: [STDS-802-11-TGBE] SP#4 of doc 358

 

CAUTION: This email originated from outside of the organization.

Hello Abhi and Pooya

 

Thanks for this discussion. I thought about the independent case, similar to the example raised by Abhi. But meanwhile we still need think about its benefit. In my mind, both Limitation and independent cases have almost the same performance on the network, and satisfy the network configuration. It is similar to the restriction that AP MLD is STR. Limitation is not to mandate the creation of a BSSID (my previous response may be not exact), it is just to decrease a few unnecessary configuration cases due to limited benefit. I just went though 11-20/357, I observed that it brings MLA element to Multiple BSSID element and it requires both an independent MLA element and Multiple BSSID element which also contains MLA element (it is not a clear advertisement). And I am not sure whether it can perform the complete function. A question to Abhi, could the figure in slide 11 advertise the info of all the APs shown in slide 3 or just partial of them? Do you consider the coexistence when transmitting Multiple BSSID element? Just double check if we are in the same page.

 

By the way, Pooy, my answer to your question in chat window is not exact. No any further optimization is needed if it has a limitation like what I mentioned below, otherwise it may bring some complexity.  

 

Best wishes,

Ming Gan

 

发件人: Pooya Monajemi [mailto:00000ef0b9e0aff7-dmarc-request@xxxxxxxxxxxxxxxxx] 
发送时间: 2020510 5:27
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] SP#4 of doc 358

 

Hi all,

Just to weigh in, I think I agree with Abhi here, mandating the creation of a BSSID just to support the signaling sounds complex and restrictive. There are use cases for not wanting all MLDs on all links.

 

Regards

Pooya 

 

 

On Friday, May 8, 2020, 08:03:02 AM PDT, Abhishek Patil <appatil@xxxxxxxxxxxxxxxx> wrote: 

 

 

Hi Ming,

 

Thank you for your response.

 

Multiple BSSID is a per-link concept and we should not artificially add constraints to this feature for possible signaling benefits for multi-link operation. Let’s view this from a functionality point of view. Multi-link is a new feature which should work without requiring us to introduce limitations to an existing (legacy) feature.

 

You mentioned that we could artificially configure MBSSID set. It is not that simple. What you are suggesting is to add a BSSID within the multiple BSSID set to take on the role of TxBSSID (in my example below). However that has repercussions – such as, advertisement of the profile, managing the STAs that associate with that BSSID, ACK sessions, security etc. In addition, when the configuration on one link were to change, it will have a ripple effect to the configuration on the membership of MBSSID sets operating on other links. Please consider these factors when you  weigh in the perceived benefits of adding artificial constraints.

 

We have some thoughts on the signaling. It is not very complicated as you may thing. We have discussed it in another contribution (11-20/357).

 

Regards,
Abhi

 

 

From: Ganming (Ming) <ming.gan@xxxxxxxxxx> 
Sent: Friday, May 8, 2020 6:01 AM
To: Abhishek Patil <
appatil@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 
答复: SP#4 of doc 358

 

CAUTION: This email originated from outside of the organization.

Hello Abhi

 

Thanks for initiating this follow up discussion. You raised a good example. I am also thinking about its benefit. You know, Multiple BSSID set could be artificially configured. In your example, another virtual AP could be created on link 2 for MLD 1. This limitation (the AP MLD has the same type of BSSID APs, either TX BSSID or non-TX BSSID) will not harm the clients, and also could satisfy their different requirements, such as SSID or security. On the other hand, it will simplify the advertisement: one AP MLD element which contains all the AP Info, and a Multiple BSSID element for a AP in AP MLD which is in Multiple BSSID set. The structure is quite clear.  If AP MLD contains different types of BSSID APs, then it is a little bit difficult to carry Multiple BSSID element or interpret the meaning of Multiple BSSID element if it is sent without the info of TX BSSID. All of these two options are described in Liwen’s contribution 396/r0. What do you think about this?

 

By the way, why is not there a time slot for the presentation 396/r0?

 

Best wishes

Ming Gan

 

发件人: Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx] 
发送时间: 202058 16:02
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] SP#4 of doc 358

 

Hi Ming,


Following up on our discussion during today’s call.

 

Per SP#4 in doc 358, an AP of an MLD could correspond to TxBSSID or nonTxBSSID independent of another AP of the MLD being TxBSSID or nonTxBSSID.

 

If we were to follow your suggestion and put a requirement that all APs of an AP MLD to be either TxBSSID or nonTxBSSID, which BSSIDs should be TxBSSIDs in the following example? 

 

 

<image002.png>

 

Multiple BSSID set or Co-hosted BSSID set are per-link features and should be kept that way.

 

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


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


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