| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 |