Hi Mike,
Thanks for the feedback. Just to explain more on the situation here.
I agree that we have spent a lot of times on making sure that we just extend association from STA level to MLD level so that the upper level DS knows the one entity that we are talking about. The term that we use to clarify
this is MLD association (or if you prefer association between two MLDs). The text in 11.3 does address that.
The link setup procedure is something on top of the association service provided to the DS, where request frame indicates the links requested to be setup and the response indicates the links accepted to be setup.
I respond to Payam in another email not on the reflector that if we really want to improve we can have editorial change to say links setup procedure under MLD association or something like that. The link setup procedure is
something new for MLD since we have multiple links for the first time in 802.11 spec.
Best,
Po-Kai
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, May 19, 2021 1:58 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/0390 | CIDs 3316, 2313
Hi Po-Kai,
I agree with Payam on this one. Given that we've been nailing down the ML Architecture, the connection and state transitions between MLDs still involves Discovery, Authentication, and Association, As a matter of fact, the text that I believe
you contributed to in 11.3 provides requirements on how this process works.
It's better and clearer to use ML Association. At this point, we should transition the draft away from ML Setup towards ML Authentication and ML Association. We already use ML Discovery (Note that I hate ML Probe :-) )
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
Hi 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
My understanding is that what we are discussing is a naming issue. I think ML association is easier for people to understand.
Regards,
Yunbo
Hi Po-Kai, no problem with that — it’s just called MLD association. The process/signaling can still be called ML association.
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
I agree with Payam. ML re/association is more accurate. Setup means lots of things, ML TWT setup, ML WNM setup…
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
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
|