| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Thanks, Po-Kai, Reponses, also in-line. Mark From: Huang, Po-kai <po-kai.huang@xxxxxxxxx> Hi Mark, I provide the comments below for the suggestion. Best, Po-Kai From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx> John/all, 1) While I’m okay with a reference to body (sub)clauses from within clause 3, I think having a definition which cannot be understood without reading the body subclause is not appropriate. Thus, I’m not happy with the new definition for BSS transition: basic service set (BSS) transition: Change of association by a station (STA) [10512] or non-AP MLD while remaining within the same extended service set (ESS) as defined in 4.5.3.2 (Mobility types). as it seems the only way to know what sort of “change” to the association constitutes a BSS transition, is to read 4.5.3.2. (There are lots of ways to “change” an association; we’re trying to narrow this to be the movement from one BSS/MLD to another, as the change that is relevant here.) May I suggest instead: basic service set (BSS) transition: [Po-Kai]: I have some discussions with John on this. The reason for seeing 4.5.3.2 is that we have 4 bullets now for STA to STA case, STA to MLD case, MLD to STA case, and MLD to MLD case. The tricky part is that when STA move to AP MLD, it will use non-AP MLD entity. 4.5.3.2 have detailed description to have everything captured. The above simplified version does not capture this, and may look like STA may directly connect to MLD. This is the reason why I suggest to have reference and keeps the description more general as proposed in John’s doc. [[MAH]] 1) I believe the definition is that this is a transition from BSS or AP MLD to another BSS or AP MLD. The details of how that happens are interesting/important, and need to be detailed, as they are in 4.5.3.2, but are not important to the definition of this concept. The concept is simply that this is one of those transitions. That said, I think the proposed definition, which doesn’t even say that it is one of those four types of transitions (but instead tells the reader to go read 4.5.3.2 to figure that out) is imappropriate. I think this wording is consistent with the ways BSS-transition is described in 4.5.3.2, and is self-sufficient. 2) I’m also uncomfortable with the changes to the definition of fast BSS transition, as now it says the security association (etc.) must be transitioned _before_ the reassociation, while I think it is somewhat before, and somewhat during, the reassociation. We actually debated the current definition a fair bit in REVm<x> trying to prevent this. (But I applaud your use of “BSS transition” so that we don’t have to repeat all that stuff, like the current definition does.) [Po-Kai]: The following sentence is from the baseline directly. Hence, I think there is no issue for the correctness. A fast BSS transition is a BSS transition that establishes the state necessary for [[MAH]] I’m not sure what baseline you’re referencing. In both IEEE 802.11-202 and REVme D1.4, the definition of “fast basic service set transition” is currently, “Change of association by a station (STA) that is from one BSS in one extended service set (ESS) to another BSS in the same ESS and that minimizes the amount of time that the data connectivity is lost between the STA and the distribution system (DS)”. I gather you’re talking about some other sentence somewhere, which does not seem relevant to this CID. Such a sentence might make sense in context. But, with no other context (which is how definitions are supposed to be written), we should be clear and complete. To say the state is established before the reassociation is not clear, and is in fact confusing. May I suggest instead: fast basic service set (BSS) transition: A BSS transition that minimizes the amount of time that the data connectivity is lost between the STA and the distribution system (DS). 3) I hesitate to go here, but reviewing these made me see what I had missed in earlier reviews of 11be draft: that the definition of MLD says the entity has to provide the MAC SAP to the LLC sublayer. Note that on an AP, there is no LLC sublayer (in the controlled port side, anyway, so for all non-EAPOL data frames) – see 5.1.5.3 of 802.11-2020. The same is true for an AP MLD. May I suggest we just remove “to the logical link control (LLC) sublayer” from the end of this definition? [Po-Kai]: John will transfer the CID related to MLD definition to me. My understanding for having LLC sublayer is that in the baseline, we say data service provides peer LLC sublayer to exchange MSDUs. Hence, we say we have one MAC SAP for the LLC sublayer. 5.1.1 Data service This service provides peer LLC sublayer entities or IEEE 802.1Q bridge ports with the ability to exchange [[MAH]] The data service you’re talking about here is for the overall 802.11 “system”, which does transfer data (MSDUs) from one LLC sublayer entity (or 802.1Q bridge port in the case of GLK) to another. However, a given MLD, and in particular an AP MLD, does _not_ transfer data to an LLC entity, it transfers the data to the DS. To say/imply that an AP MLD transfers data to the LLC sublayer is just plain incorrect. And, further, to have the definition of an MLD appear so different (in this respect) to the definition of a STA makes no logical sense – they serve basically the same function, just with different underlying methods. Part of the point of 11be is that in the end, the non-AP MLD and AP MLD appear the same to the rest of the network structure to be performing the same function as the non-AP STA and AP used to perform. Thanks. Mark From: Wullert, John R II (PERATON LABS) <jwullert@xxxxxxxxxxxxxxx> Alfred, Would you please add document 802.11-22-1255r1 to the queue. This addresses 19 CIDs dealing with the definitions in Clauses 3.1 and 3.2. This document has been reviewed by several of the commenters. If others have comments/suggestions, please provide via the reflector. Thanks, John From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx> Hi Alfred, Could you kindly help move the following document from the TGBe MAC technical submission queue to the TGbe MAC CR queue? The r1 version is now a PDT instead of a PPT.
It resolves 1 CID. Regards, Vishnu From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Hi Alfred, Liwen, Jeongki, Could you please help add the following doc to the TGbe MAC agenda? 11-22/1354: LB266: Resolution for CID 10611 It resolves 2 CIDs. Regards, From: Morteza Mehrnoush <000012bde833b015-dmarc-request@xxxxxxxxxxxxxxxxx> Hi Alfred, Can you please add the following CR doc to the MAC queue?
Thanks, Morteza From: Eunsung Park <esung.park@xxxxxxx> Hi Alfred, Sigurd and Tianyu, Please add the following CR document to the PHY queue. - 11-22/1358r0 LB266 CR for CID 11343 and 12145, Eunsung Park, LG Electronics (2C) ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd Hi Alfred, Sigurd and Tianyu, Please add the following CR document to the PHY queue. 11-22/1358r0 LB266 CR for CID 11343 and 12145, Eunsung Park, LG Electronics (2C) Best regards, Eunsung From: Eunsung Park [mailto:esung.park@xxxxxxx] Hi Alfred, Sigurd and Tianyu, Please add the following CR documents to the PHY queue. 11-22/1288r0 LB266 CR for CID 11341, Eunsung Park, LG Electronics (1C) 11-22/1289r0 LB266 CR for 36.3.2.6 RU and MRU restrictions for 20 MHz operation, Eunsung Park, LG Electronics (2C) Best regards, Eunsung From: Eunsung Park [mailto:esung.park@xxxxxxx] Hi Alfred, Sigurd and Tianyu, Please add the following CR documents to the PHY queue. 11-22/1226r0 LB266 CR for Equations in 36.3.12.9 EHT-STF, Eunsung Park, LG Electronics (2C) 11-22/1227r0 LB266 CR for 36.3.2.3 Null Subcarriers, Eunsung Park, LG Electronics (1C) Best regards, Eunsung From: Alice Jialing Li Chen [mailto:jialing.li.phd2@xxxxxxxxx] Hi Alfred, Could you please add the following CR document to the PHY queue?
Thanks, Alice On Thu, Jul 28, 2022 at 6:53 PM 李雅璞(Yapu) <00001b0ec2563bd4-dmarc-request@xxxxxxxxxxxxxxxxx> 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 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 |