Hi Rojan and Abhi
Thanks a lot for the comments.
I agree with what you all mentioned, of course, i.e., if we have an ML IE in Assoc. frames, it is ML setup, which follows the current draft
If I clarify the discussion point I’m trying to make, it basically depends on the first sentence in 35.3.5.4
“A non-AP MLD may initiate a multi-link setup with an AP MLD to setup or “more than one link (Opt 1)” or “one or more link (Opt 2)” with a subset of APs, …”
It means that “the case when a non-AP MLD requests one link only”
Option 1: it is “always” treated as legacy association. So, the case does not carry ML IE
Option 2: it can be the ML setup by including ML IE (only Common Info)
The original version was based on Option 2, but I also received the feedback that we should go with option 1 as previously.
In addition, I’ll fix the part regarding Status Code field in the next revision.
Thanks
Best Regards
Insun
From: Rojan Chitrakar [mailto:rojan.chitrakar@xxxxxxxxxxxxxxxx]
Sent: Tuesday, May 25, 2021 8:56 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] ML IE usage for ML setup
Hi Abhi,
Thanks for your clarification, so I guess the “Per-STA Control field” below in Insun’s text should be changed to “STA Profile field” instead right?
“… in the Status Code subfield of the Per-STA Control field of the Basic variant Multi-Link element…”
I guess this is what was just discussed on the MAC call for 390r2 as well.
Regards,
Rojan
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Tuesday, May 25, 2021 2:09 AM
To: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] ML IE usage for ML setup
Hi Rojan, Insun,
Please see my comments in-line below in green:
Regards,
Abhi
From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Monday, May 24, 2021 3:21 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] ML IE usage for ML setup
CAUTION: This email originated from outside of the organization.
Hi Insun,
Thanks for sharing.
Regarding your discussion point, is it possible for a STA affiliated with a non-AP MLD to send an Association Request frame (without ML element)? If yes, isn’t that enough to signal legacy Association? If an ML Element is included in the Association request frame, I would think it should be considered ML association. What is the reason to include ML element for legacy Association?
I agree with Rojan – If a (Re)Assoc Req frame does not include ML IE, the association (if successful) would be considered as legacy association. If the Req frame were to include ML IE, then it is considered to be a multi-link setup with one or more links. This approach will help keep the procedures involved in legacy vs MLO association clear.
Two quick questions regarding the text:
1) Is the Status Code subfield of the Per-STA Control field of the Basic variant Multi-Link element a new field, or is it already defined? If not defined, we need to add it in clause 9.
The Status Code field will be carried within the STA Profile field – please see 35.3.2.2 – the STA Profile carries fields and elements:
In addition, the bullet describing the content of STA Profile field clarifies that it includes fields carried in the corresponding frame:
2) regarding below text:
When the AP affiliated with the AP MLD cannot accept the link on which the (Re)Association Request frame was received, the AP shall treat the multi-link (re)setup as a failure and indicate in the Status Code field the reason for not accepting the link.
Where is this Status Code field located? Would be good to clarify. In this case, is it still necessary to include Per-link Info for all the other links since the request is rejected?
Please see above response regarding location of the Status Code field.
If the AP MLD does not accept the link where (Re)Assoc Req frame is received, then the entire ML setup fails.
It may be useful to provide the Status Code for each of the other link so that the non-AP MLD has more information – such as, the AP MLD was Ok with the other link and that the non-AP could try to perform ML setup that involves the ‘acceptable links’.
Regards,
Rojan
From: 장인선 <insun.jang@xxxxxxx>
Sent: Monday, May 24, 2021 3:47 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] ML IE usage for ML setup
Hi all,
I’ve updated the CR-PDT related to ML IE usage for ML setup (21/499r2) based on offline feedback. Thanks all
Especially, I’ve provided two options and relevant texts for the following issue as a discussion point.
“When a non-AP MLD with more than one STA requests one link only (where Assoc. Request frame is transmitted), it shall be considered as the legacy association or ML setup”
Please review that before the discussion in the call, and let me know if you have any opinions on the document.
Thanks
Best Regards
Insun
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