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