| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Ming, Thank you for the email discussion on this topic. Could you please elaborate the following statement that you made in your response? >> because AP will broadcast the Counter for a few APs in the AP MLD. However, how does the STA know which counter is for which reported AP. When you say ‘few’ are you saying subset of reported APs or for all the APs of the MLD? If an MLD has 3 APs, the reporting AP must include the counter for each of other 2 APs. Regardless of whether the counter is carried in per-AP entry in RNR or per-AP profile in MLA IE, it is clear associated with a particular AP entry. Below, I provide an example with respect to RNR since the structure of RNR is already defined in the spec. Structure for MLA IE is yet to be defined so I don’t want speculate. RNR is required to carry information of the APs of an AP MLD – we already passed an SP on that matter. Let’s an AP on 2.4 GHz when reporting other APs of it’s MLD (operating on 5 GHz and 6 GHz) will have (two)
separate Neighbor AP entries. Further, for each AP entry there will be an indication in the RNR to say if a reported AP is part of the same MLD (most likely this will be a single bit in the existing BSS Parameters field or a new field added for MLO). Since
the AP entries are distinct in RNR, we don’t need a separate identifier to associate the counter field to an AP. It is naturally affiliated with that AP entry. The counter field would need be a new field added to the AP entry for the APs that belong to the
same MLD as the reporting AP or MLDs to which a nonTxBSSID on that link is affiliated with if the reporting AP is TxBSSID. The situation would be the same when the counter is carried in the per-AP profile in MLA IE. There could be other reasons why we link identifier. That debate is yet to happen and when we get to it, we can discuss the benefits. But for the case of critical updates counter, I don’t see a reason why we need a another field (e.g., link ID) to identify the corresponding AP. Regarding RNR vs MLA IE: RNR is already required to carry information of other APs of the MLD Therefore, this field can be a simple extension (1 byte). With the objective of reducing the mgmt. frame overhead. Regards, From: Ganming (Ming) <ming.gan@xxxxxxxxxx> CAUTION:
This email originated from outside of the organization. Hello Sharan,
Thanks for your response. Please see my response inline. Best wishes, Ming Gan 发件人:
Sharan Naribole [mailto:n.sharan@xxxxxxxxxxx]
Hi Ming, Thanks for your contribution and reflector discussion! I have a few questions. SP 1: I have similar questions as Abhi. I didn’t understand the motivation for Link ID/TBD ID here. Doesn’t RNR already have fields like BSSID, Co-Located AP, etc. for non-AP MLD to
identify that this reported AP is another AP of the same AP MLD? What’s missing? [Ming] because AP will broadcast the Counter for a few APs in the AP MLD. However, how does the STA know which counter is for which reported AP. So counter shall be used together with
the identifier of the AP. Otherwise, it can not work. Abhi argued that RNR already have a identifier for the reported AP, e.g., BSSID, so it is not necessary. I guess Link ID will be in RNR to identify the reported AP. To make people comfortable, especially
Abhi, I change “Link ID” to TBD field. Note that, RNR is not good container now. Otherwise, it will force every associated STA to decode it. It does not make sense. But I agree that we should reuse the existing element as
much as possible. SP 2: Strange wording “shall support to receive the next beacon frame sent by reported AP to retrieve the
update” What if the non-AP MLD does not intend to use the other link in near future? Don’t see why it should wake up and
shall attempt receiving next Beacon. I agree with concern to reduce Probing but your SP text is the most extreme way to address it. Perhaps your intention is to recommend non-AP MLD to receive BSS Parameter Updates of a link via Beacon/Broadcast Probe
Response/unsolicited mechanisms before operating on a link for which it has received updated Change Sequence number. SP 3 is not required IMO and suggest removing it. [Ming] First, we are aligned with the issue of Probe. It could be disaster if every STA simultaneously contends the channel to send Probe Request when there is update. Receiving beacon
is better way. Actually it is not strong (baseline in the Spec) , otherwise, it misses some important update, for example, channel switch, such that it can not operate correctly when it intends to operate on that link.
Thanks, Sharan From: Ganming (Ming) [mailto:ming.gan@xxxxxxxxxx]
Hello all, As per the request, I post my SPs in DCN 0503/r2 here for the group discussion. I was open to add the changed sequence number field to RNR element or ML element. However,
I changed my mind after hearing the Yong’s comment. Yong’s comment is valid, RNR is for basic discovery. However, BSS parameters update notification per BSS belongs to BSS/link management, so we can not mix them together. Regarding ML element, it meets the
same issue, it just is used for providing the capability, operating info of a reported AP. We can think about it more. To make Abhi comfortable, I use TBD field instead of Link ID. Hope you are fine with this. After being formed the changed BSS parameter of a reported AP, Laurent mentioned that we should remove the “next” from “next beacon”. Actually it is the baseline in
the subclause “TIM Broadcast”. If you ask me why, maybe because the pending communication can not be predicated. Moreover, receiving a beacon frame does not harm much.
Please tell me if you have any suggestion or comments on the following SPs, thank you. SP 1
SP 3
SP 4
Best wishes, Ming Gan 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 |