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