Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] 11-21/0390 | CIDs 3316, 2313



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 :-) )

 

Cheers,


Mike

 

 

 

On Wed, May 19, 2021 at 11:02 AM Payam Torab <torab@xxxxxxxx> wrote:

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, 2313

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

 

 

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]
发送时间: 2021519 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]
发送时间: 2021519 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


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