| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Mike and All,
This topic is one I have commented on frequently and I have been doing so since MLO was first proposed.
From an architecture perspective I have significant issues with the term: affiliated STA, as it implies that the affiliated STA is a type of STA. It is not.
An affiliated STA is the “lower” MAC and PHY that is supporting the MLD with access to a specific RF link (channel). It is not a STA, as a STA is: “station (STA): A logical entity that is a singly addressable instance of a medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM).” (IEEE 802.11REVme D1.3). The phase “singly addressable instance of a MAC” means the STA must have a MAC SAP and that that MAC SAP is addressable by higher layers.
The current definition in 802.11be D2.1 for affiliated STA is: “affiliated STA: A station (STA), which can be an access point (AP) STA or non-access point (non-AP) STA, that provides link-specific, lower medium access protocol (MAC) services within a multi-link device (an MLD).”
This definition is impossible as it contradicts its self: a STA provides a MAC SAP to PHY interface to the WM, but an affiliated STA only provides lower MAC to PHY interface to the WM. Services are only provided at a MAC SAP accessible to the higher layer using the service. The current draft defines no such interface for the affiliated STA, nor does the affiliate STA provide an external service, only provides the lower MAC to PHY interface to the WM for an RF link (channel) of the MLD. The MLD has a MAC SAP and therefore provides a service, similar to that performed by a STA (MAC SAP to WM).
Until, we can resolve this fundamental issue I don’t see how we can have any clarity in the specification as we are using defined terms in ways that are contradict there meaning in other part of the specification.
One example of this is statements in the draft that state that an affiliated STA has state related to Authentication/Association. The term “state” in the 802.11 specification is used to describe many concepts, e.g.,: Authentication/Association State, Power Save (awake and doze state), Transmit State Machine, Buffer State, NAV state, RID state, busy/idle state, … . So the use of the term “state” is used to describe the states of multiple state machines and unless the context is clear its use can be confusing.
But, when the specification talks about the Authentication/Association State of a STA it is very clearly referencing the STA state described in clause 11.3 STA authentication and association. The allowed states for a non-AP STA listed in 11.3.1 (States 1-4) and are shown in Figure 11-21. These states restrict what frame types the STA may send and are essential for understanding STA behavior during authentication and association. A similar set of states are necessary for an MLD to be authenticated and associated with an AP MLD. Since authentication/association state is related to services and services are provided at the MAC SAP, these authentication/association states only apply to the MLD, as a MAC SAP is essential to these states having any meaning. Affiliated STAs do not have a MAC SAP and do not provide services and hence cannot have an authentication/association state. Therefore, statements in the 802.11be draft that say affiliated STAs have an authentication/association state are incorrect and should be removed.
e.g., (802.11be D2.1 428.58) “After multi-link teardown, all the non-AP STAs affiliated with the non-AP MLD and the non-AP MLD are in the unassociated state (see 11.3.2 (State variables)).” This sentence makes no sense as only the non-AP MLD has a state in the sense of 11.3.2, the affiliated non-AP STAs never and will never have a state. The only entity that that has an authentication/association state for MLO is the non-AP MLD and the specification should be clear on this.
Regards,
Joseph
From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Sent: Thursday, August 11, 2022 2:25 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Discussion on 'STA' vs 'non-AP STA' affiliated with a non-AP MLD
Hi Abhi,
I support to specifically call out the form.
For me, this is important because “STA” in the baseline are often used when it applies to both AP and non-AP STAs. If we are talking about “non-AP MLD”, then the affiliated STA is “non-AP STA”.
I will also provide another experience that I have during 11ax days.
11ax introduces Trigger frame and Trigger frame can only be sent by AP and triggered non-AP STA. For this specific technical reason, we call out AP/non-AP STA in basically all the places to clarify this confusion rather than just using “STA” and using the fact that we only have Trigger frame sent from AP to take care of this.
Best,
Po-Kai
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, August 11, 2022 10:11 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Discussion on 'STA' vs 'non-AP STA' affiliated with a non-AP MLD
Hi Abhi,
Thanks. For MLO according to the state machines defined in clause 11.3, connectivity state is established between a non-AP MLD and an AP MLD. These entities communicate over links
between an affiliated STA and affiliated AP. Yes this phraseology is used throughout TGbe but I'd like those commenting on the ambiguity to review the draft and call out
specific locations where the meaning is ambiguous. Perhaps we could address those areas where the context isn't clear.
Thanks,
Mike
On Thu, Aug 11, 2022 at 1:00 PM Abhishek Patil <appatil@xxxxxxxxxxxxxxxx> wrote:
Hi All,
I’d like to follow up on the topic we discussed during today’s TGbe MAC call (‘STA’ vs ‘non-AP STA’).
There were different opinions on the topic. I personally like explicitly calling out “non-AP STA affiliated with a non-AP MLD”. I know it is a bit lengthy but it align with the definition of a non-AP MLD and avoid any ambiguity (as pointed out by the two comments).
“non-access point (non-AP) multi-link device (MLD): An MLD, where each station (STA) affiliated with the MLD is a non-AP STA.”
11714
Gaurav Patwardhan
406.01
"A STA" and "A non-AP STA" is used interchangeably many times during Clause 35. Need to replace all the relevant occurences of "A STA" with "A non-AP STA". Commenting on this particular line as a placeholder.
as in comment
10942
Graham Smith
406.38
I see many instances of "STA affilicted with a non-AP MLD". Is this really also for an AP with a non-AP MLD? Just checking. Should it be" non-AP STA affiliated with a non-AP MLD"?
Just check if this is for both a "non AP STA affililiated with a non-AP MLD" AND a "AP affililiated with a non-AP MLD"?
I’d like to hear more thoughts on this item and hopefully conclude before the next TGbe MAC call (Monday 15th Aug) so that we can resolve the two comments during that call.
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
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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature