Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Po-Kai, I still can’t see “ML association” instead of “ML setup” causing any confusion,
- ML association: Procedure of associating two MLDs; since it is “ML” association it is understood there is one DS interface
- MLD association: invoking the association service (providing the non-AP MLD <-> AP MLD mapping to the DS)(e.g., existing references in the text don’t seem to need a change).
Re: “This works perfectly for higher layer because higher layer does not care exactly what is the entity. For them, it just one entity, and everything works exactly like before.”
That’s actually a good argument for having the name association (there is ana association happening) – “ML association” does not mean it is multiple; it means it is ML type.
Interested in hearing what other people think. Adding reflector for more feedback. Thanks.
Payam
From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Date: Wednesday, May 19, 2021 at 7:10 AM
To: Liyunbo <liyunbo@xxxxxxxxxx>, Payam Torab <torab@xxxxxxxx>
Cc: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>, Chunyu Hu <chunyuhu07@xxxxxxxxx>, Jarkko Kneckt <jkneckt@xxxxxxxxx>
Subject: RE: 11-21/0390 | CIDs 3316, 2313Hi all,
Thanks for the discussion. Just want to also clarify that for association, what we end up with is that we generalize the concept of association between two STAs to association between two MLDs. This works perfectly for higher layer because higher layer does not care exactly what is the entity. For them, it just one entity, and everything works exactly like before.
When we refer to the difference in the spec we use STA association vs MLD association. This is understood by a lot of people (ARC people specifically) to be the interaction with the DS.
Multi-link setup is something new for MLD and only relevant to our MAC layer of determining which links can be used. That term is used with the intention to make people understand that we are not designing something that higher layer needs to be aware of.
Best,
Po-Kai
From: Liyunbo <liyunbo@xxxxxxxxxx>
Sent: Wednesday, May 19, 2021 7:05 AM
To: Payam Torab <torab@xxxxxxxx>; Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Cc: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Chunyu Hu <chunyuhu07@xxxxxxxxx>; Jarkko Kneckt <jkneckt@xxxxxxxxx>
Subject: 答复: 11-21/0390 | CIDs 3316, 2313
My understanding is that what we are discussing is a naming issue. I think ML association is easier for people to understand.
Regards,
Yunbo
发件人: Payam Torab [mailto:torab@xxxxxxxx]
发送时间: 2021年5月19日 21:54
收件人: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
抄送: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Liyunbo <liyunbo@xxxxxxxxxx>; Chunyu Hu <chunyuhu07@xxxxxxxxx>; Jarkko Kneckt <jkneckt@xxxxxxxxx>
主题: Re: 11-21/0390 | CIDs 3316, 2313
Hi Po-Kai, no problem with that — it’s just called MLD association. The process/signaling can still be called ML association.
On May 19, 2021, at 6:34 AM, Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:
Hi all,
Perhaps I can elaborate more on this. What I mean is that the main meaning of (re)association in the current spec is to present one entry point to the DS.
What we have done in 11be is that under this abstraction of one entry point, we allow multiple links to be setup, which DS does not need to be aware, and there is indeed a setup procedure defined (links to be setup are indicated in (re)association request and links that are accepted are indicated (re)association response.)
Agree that setup is a general term that we have been used to be the establishment of protocol. The prefix like TWT differentiate the difference, so I do not think there is a confusion for this.
Best,
Po-Kai
From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Sent: Wednesday, May 19, 2021 2:12 AM
To: Payam Torab <torab@xxxxxxxx>; Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Cc: Liyunbo <liyunbo@xxxxxxxxxx>; Chunyu Hu <chunyuhu07@xxxxxxxxx>; Jarkko Kneckt <jkneckt@xxxxxxxxx>
Subject: 答复: 11-21/0390 | CIDs 3316, 2313
I agree with Payam. ML re/association is more accurate. Setup means lots of things, ML TWT setup, ML WNM setup…
发件人: Payam Torab [mailto:torab@xxxxxxxx]
发送时间: 2021年5月19日 14:01
收件人: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
抄送: Liyunbo <liyunbo@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Chunyu Hu <chunyuhu07@xxxxxxxxx>; Jarkko Kneckt <jkneckt@xxxxxxxxx>
主题: 11-21/0390 | CIDs 3316, 2313
Hi Po-Kai, I generally agree with these comments; ML re/association seems to be a good and accurate term. The “MLD association” you are pointing to below seems to have enough distinction (I assume you are referring to such sentences: “For a non-AP MLD, the act of becoming associated with an AP MLD invokes the association service (MLD association), which provides the non-AP MLD to AP MLD mapping to the DS (see 35.3.5.1 (Multi-link (re)setup procedure)).”).
Would be good to get a sense of what this group thinks when you discuss.
Regards,
Payam
3316
Yunbo Li
130.46
35.3.5
Seems multi-link setup is the same concept as multi-link association. Do we need to keep both of them. Maybe only need to keep multi-link association in the spec.
as in comment.
Rejected –
We note that MLD association is focusing on the concept that one (non-AP MLD, AP MLD) mapping is presented to the DS.
For the additional concept of multiple links that are setup, clause 35.3.5 then describe the correspoinding procedure, where (re)association request/response are reused and links that are requested/accepted for (re)setup is then further indicated in the frame.
2313
Ming Gan
130.46
35.3.5
Multi-link setup is not correct name, change it multi-link association in this subclause
As in comment
Rejected –
We note that MLD association is focusing on the concept that one (non-AP MLD, AP MLD) mapping is presented to the DS.
For the additional concept of multiple links that are setup, clause 35.3.5 then describe the correspoinding procedure, where (re)association request/response are reused and links that are requested/accepted for (re)setup is then further indicated in the frame.
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