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