| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
As I comment earlier, I commented on this before and nothing was changed. I do not support the changes in this document .Cheers,MikeOn Fri, May 10, 2024 at 5:27 PM Binita Gupta <bingupta.ieee@xxxxxxxxx> wrote:Hi All,Please let me know if there are any further comments on the proposed changes on 11-24/699.Alfred,Could you please add 11-24/699 for SP (2 CIDs) in the TGbe MAC queue for the May meeting.Thanks,BinitaOn Sun, May 5, 2024 at 8:01 AM Binita Gupta <bingupta.ieee@xxxxxxxxx> wrote:Hi Mike,Thanks for your feedback and thanks for your offline discussion as well.Brian and I did discuss and highlighted the scenario we are trying to address with this proposal. You were unwilling to acknowledge and discuss the specific scenario itself. You indicated that you are willing to work on alternatives where AP does not reject the association. In my last email I asked you how the AP should handle the scenario when the max STA limit is reached, but didn't get a response from you.We indicated to you that this scenario happens today in AP products and we are trying to find a better solution for MLO in this case instead of just rejecting the Association. APs hardware can reach Max_STA limit and then can't accept the association. You didn't acknowledge this scenario. AP knows which other affiliated APs/AP MLD can provide association, so it makes sense for it to recommend those. It is quite a straightforward extension really.Again, you keep insisting that this proposal results in association rejection, which is not correct. This does not result in causing more association failures, any association rejection are based on already defined status codes in baseline and 11be, and we are not changing those. This proposes to assist STA to associate faster by recommending where to go next in case current AP can't accept association. So, really the ultimate goal is to help STA connect faster.Thanks,BinitaOn Sat, May 4, 2024 at 9:26 PM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:Hi Binita,Thanks for your email and proposal. While I understand why this might seem like a good proposal from an infrastructure point of view, it would cause poor and unpredictable behaviour on the client. I think it’s wrong to extend this feature to MLO and I do not support this contribution.I offered to work with you and Brian offline to address my concerns and you were unwilling to even discuss them.Cheers,MikeOn Sat, May 4, 2024 at 11:59 PM Binita Gupta <bingupta.ieee@xxxxxxxxx> wrote:Hi All,I presented CR doc 24/699r0 in the last TGbe call. Based on offline feedback I have revised the CR doc to 24/699r1.Proposed text has been simplified. It enables an AP MLD to provide recommendation for AP MLD/affiliated APs of an AP MLD using Basic ML element in the Neighbor Report element (following same rules as BTM) in the Authentication or (Re)Association Response frame that has the Status code set to REJECTED_WITH_SUGGESTED_BSS_TRANSITION. Note that this status code has been defined since "11v" and has been used by AP products for years to suggest other APs if association cannot be accepted. This CR doc proposes to extend it to MLO by using the Basic ML element in Neighbor Report, similar to BTM logic.For MLO, there is even a stronger reason for this. In the scenario when an affiliated AP of an AP MLD has reached max STA limit (say on 2.4GHz), then ML association can't be accepted when received by that AP, but other affiliated APs (5 and 6 GHz links) of the AP MLD may still be able to accept association, because limit has not been reached on those links. In this case, the AP MLD can recommend in the Authentication or (Re)Association Response to associate with the current AP MLD on remaining links. This is a better outcome than AP just rejecting the association without any recommendation. Note that the number of associated STAs is quite dynamic, e.g. when a train arrives the max STA limit can reach on the 2.4 GHz because more STAs associate on that link, but 5 and 6 GHz links can still accept association and AP should recommend those links to the STA. Also, note that in this case, AP can't advertise in advance in Beacon that it is not able to accept association, since num of STAs changes fast.Please let me know if you have any feedback on the proposed changes.Thanks,Binita
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