Hi Abhi,
I understand your explanation for CID 18091 and I am supportive of this addition. I have a question though; how will this work when AP deletes/adds links; i.e. does the AP commit to
supporting the same number of max links even after deleting/adding links (so it is a static capability), or are you expecting this number to change as links get added/deleted (so it would be an operating parameter). I expect it is the former, as currently
there is no way a non-AP MLD can react to such an operating change, but please kindly confirm.
With regards to CID 18092, I see an issue with your proposal when one or more of the links operate in EMLSR mode. D3.0 specifies that links implicitly move to PM=0 following enabling
EMLSR mode. Therefore, this new feature either limits the number of links that can enable EMLSR (so that they are always less or equal to the “number of links a non-AP MLD can be simultaneously active on”,
or the AP MLD will have no way of telling which link(s) are in active state after EMLSR is enabled.
CID 15062,
currently assigned to me, is asking to alter the EMLSR behaviour, i.e. allow the links to stay in doze mode when EMLSR mode is enabled, but my resolution plans to allow (using a newly defined capability) for the current behaviour if the non-AP MLD wants to
implicitly move all links to awake state.
How will your feature cope with this aforementioned issue, or otherwise do we need to consider always keeping the links in their current (prior to EMLSR enable) state?
Kind regards,
Michail
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: 21 March 2023 22:06
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Max allowed assoc request and max allowed active links
Hi All,
Hope you all had a pleasant trip back home.
During last week’s TGbe MAC session, we had a brief discussion related to the changes for addressing my two CIDs: 18091 and 18092. We couldn’t conclude during the session and decided to defer the CIDs. I am initiating
this email discussion to answer any questions and find suitable resolutions for the comments.
CID 18091 relates to advertising the max number of links that can be requested for associated.
Explanation: Today (in D3.0) an AP MLD has control over the outcome of an association request. The AP can reject any requested link and the non-AP MLD has no say in this. The goal of this comment is to have the AP MLD
advertise its limits which will enable the non-AP MLD to request its preferred set of links. As a result, the accepted set of links will be a subset of its preferred links - as opposed to requesting all link that the AP MLD is operating on and risk getting
rejection for the non-AP’s preferred set of links.
CID 18092 relates to limiting the number of links a non-AP MLD can be simultaneously active on.
Explanation: An AP may, for resource or other reasons, want to limit the number of links a non-AP MLD is active on. Based on this requirement, a non-AP MLD can adjust the number of links it indicates PM=0. There can be
circumstances (e.g., out of range on 5/6 GHz) where the non-AP is unable to signal PM=1 on certain link(s). In such case, the AP MLD assumes the most recent ‘L’ links as the links where the non-AP is in active state.
Each of the above advertisements are optional and depend on the AP MLD’s capabilities. In addition, it is optional for a non-AP MLD to support either. If a non-AP MLD has not indicated support, then AP MLD manages the
limiting by controlling the number of links the non-AP MLD can associate on which is same as today. Again, the objective is to advertise the information upfront so that the non-AP MLD can make informed decisions and thus have a better experience.
Please let me know if you have any thoughts on this topic.
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