| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello Laurent, Regarding first SP 1, I explained it in previous email, maybe you missed it, I put it here There may be more than one Change Sequence Number for several reported APs. So in this case we need a tuple <Change sequence number, Identifier of the reported AP>, otherwise, the
STA can not understand the meaning of Change Sequence Number. As you mentioned, the identifier of the reported AP could be in RNR without link ID, like BSSID or something. But TBD field for this reported AP’s identifier does not conflict with it, it could
be an existing field. In this way, we could avoid the unnecessary debate on the function of “Link ID”.
Later, we can debate the location of this reported AP’s identifier. Best wishes Ming Gan 发件人: Cariou, Laurent [mailto:laurent.cariou@xxxxxxxxx]
Hi Ming, Young Hoon, I think the wording from Young Hoon is right and better and I think that’s what we converged on in the call last time this was discussed. For your SP1 Ming, I would have the same comment as on the call: a field is not necessarily needed to identify the reported AP, as it will be included in a part of the RNR for instance which is dedicated to a reported
AP. Thanks Laurent From: Young Hoon Kwon <younghoon.kwon@xxxxxxx>
Hi Ming, Thanks for the SPs, and I have comments on SP3. In this SP, the corresponding STA “shall” attempt to receive the “next” beacon frame. But, I don’t think this is right approach. Let me give you an example. Let us say a non-AP MLD setup 2 links with an AP MLD, and one of the links (Link2) is disabled for the non-AP MLD. Then, if the Change Sequence Number for Link2 is updated, unless the non-AP MLD plans to enable Link2 again, there’s no need for the non-AP MLD to receive the next beacon frame on Link2. And, the non-AP MLD is only required
to retrieve the most recent parameters right before the non-AP MLD enables Link2 and begins to access Link2. In other words, what is important is that the non-AP MLD shall not operate on a link until it retrieved the most recent parameters for the AP operating on that link, and when to retrieve (beacon frame on link2) is not
an issue as long as it has the most recent parameters. Maybe, what you want to do with SP3 and SP4 are something similar to:
•
the non-AP MLD shall not operate on the link until it retrieved the most recent parameters for the AP operating on that link
o
The non-AP STA may retrieve the most recent parameters by receiving a beacon frame from the AP or sending a probe request frame to the AP
o
The non-AP STA may determine that it does not have the most recent parameters by receiving a change sequence for that AP that is different than the change sequence it stored for that AP How do you think? Thanks, Young Hoon From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Hello all Please tell me if you have any comments on the following sps SP 1
•
Do you agree to amend the SP #77 by adding the following bullet?
–
The reported AP in the AP MLD is identified by a TBD field, which is used together with Change Sequence Number field SP 3
•
Do you agree that when a STA in a non-AP MLD receives a Change Sequence Number field that is different from the previously received Change Sequence Number
field for a reported AP in an AP MLD, the corresponding STA in the non-AP MLD shall attempt to receive the next beacon frame sent by reported AP to retrieve the update if any STA in the non-AP MLD does not intend to send Probe Request frame to retrieve it? SP 4
•
Do you agree that when a STA in a non-AP MLD receives a Change Sequence Number field that is different from the previously received Change Sequence Number
field for a reported AP in an AP MLD, any STA in the non-AP MLD may send the Probe Request frame to retrieve the update for the reported AP? Best wishes, Ming Gan 发件人: Ganming (Ming) [mailto:ming.gan@xxxxxxxxxx]
Hello Abhi, I just want to express there may be more than one Change Sequence Number by using “a few” reported AP. So in this case we need a tuple <Change sequence number, Identifier of the
reported AP>, otherwise, the STA can not understand the meaning of Change Sequence Number. Even if this change sequence number field is in RNR without link ID, there is a identifier for this reported AP, e.g., BSSID, so I use TBD field for this reported AP’s
identifier to avoid the unnecessary debate on the function of Link ID. By the way, this reported AP’s identifier is really needed for BSS parameter update notification. Later we could discuss the position of this Change Sequence Number, I believe you understand Yong’s comment. Best wishes Ming Gan 发件人: Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx]
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
•
Do you agree to amend the SP #77 by adding the following bullet?
–
The reported AP in the AP MLD is identified by a TBD field, which is used together with Change Sequence Number field SP 3
•
Do you agree that when a STA in a non-AP MLD receives a Change Sequence Number field that is different from the previously received Change Sequence Number field for
a reported AP in an AP MLD, the corresponding STA in the non-AP MLD shall support to receive the next beacon frame sent by reported AP to retrieve the update? SP 4
•
Do you agree that when a STA in a non-AP MLD receives a Change Sequence Number field that is different from the previously received Change Sequence Number
field for a reported AP in an AP MLD, any STA in the non-AP MLD may send the Probe Request frame to retrieve the update for the reported AP? 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 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 |