Hi, Jay, I have a different interpretation of the definition of “affiliated STA” (AP or non-AP). As Joe quoted, the definition 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).” But, note that nothing in this definition says that the lower MAC services is the _only_ thing the affiliated STA can do while it is providing those services. As Joe noted, the definition of a STA says that it provides all the services from the MAC SAP, down to/through the PHY. So, because an affiliated STA is a STA (explicitly), it must provide those services. It _also_ provides the lower MAC services within an MLD, as a second function. I think that is correct/fine, and works for both the affiliated AP and the affiliated non-AP STA, and is consistent with the Figures. Mark From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Saturday, August 13, 2022 6:20 PM
To: mark.hamilton2152@xxxxxxxxx; 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 Mark, When I read Thomas’s and Jose’s comment, I think there is an issue in Figure 4-30C. From the definition of affiliated STA, the affiliated AP should only has the low MAC function. The fact is that each affiliated AP has its own High MAC, SME, MAC-SAP, etc. in Figure 4-30C, as a normal AP does. Separating the definition of “affiliated AP” from “affiliated STA” may have address such concern. Thanks Best Regards Jay Yang Those interested in this thread are probably also interested in CIDs that I am supposed to be shepherding through a TTT, on clause 4.9.5 (although I’ve been negligent getting that discussion started). So, I’d like to jump in with a general question, and see what responses are: Several of the comments on 4.9.5 reference that the SAPs are not clear, for example in Figures 4-30c and 4-30d. I note that clause 4, in general, is a bit “loose” with when or how accurately the MAC SAP is described. Rather, we generally refer to clause 5 (and Figures like 5-1, 5-2, and now 5-2a and 5-2b) for specifics about the MAC SAP. However, I could see how adding reference to the MAC SAP in Figure 4-30c and 4-30d might be helpful. I’d note that I think this is simply noting that the arrows where “[xxx] Data frames” go in/out of the upper MAC sublayer is the point where the MAC SAP exists. To extend this to Joe’s discussion below, I think by adding these MAC SAP designations, we can see that the affiliated “STA” (AP or non-AP) does include a MAC SAP. To Thomas’ point, on the non-AP MLD, that MAC SAP is shared by both affiliated [non-AP] STAs, but it does exist within each affiliated [non-AP] STA. Is this agreed? Is this helpful to add/discuss in clause 4? Thanks. Mark With reference to Figures 4-30c and 4-30d, I think the issue here is that the scope of an affiliated (non-AP) STA is different to that of an affiliated AP. Observing the dotted lines, the affiliated AP includes the non-MLD upper MAC, but does not include the MLD upper MAC. Whereas an affiliated (non-AP) STA includes both the lower MAC and the MLD upper MAC (which is mutually shared by the affiliated STAs). The definitions may well need updating; I see a related thread about explicitly calling out "non-AP" STA/MLD which might help there. 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 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 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. 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 | 35.3.2.1 | 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 | 35.3.2.1 | 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
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 |