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]
发送时间: 2020年5月8日 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?
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