| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Abhi, In one example, as you mentioned, the non-AP MLD needs to retrieve critical update information of another link, and the information of the transmitting link is not needed. In that case,
the AP can only carry the information of another link in the multi-link element, and the information of the transmitting link is not carried in the MLD probe response. Since the information of the two links are not always the same, it is better not to carry
the information of the transmitting link all the time. In another example, the non-AP MLD may only want to know some partial information (e.g., two or three IEs) of another link, it makes no sense to carry the information of the transmitting
link, since it’s not needed at all. The inheritance rule is not changed. In the first example, all elements of another link is carried in the multi-link element, there’s no need to inherit from the transmitting link.
In the second example, the “complete profile” field is set to 0 in the multi-link element in the MLD probe response, the inheritance rule is not used. Best, Jason 发件人:
Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx] Hi Jason, The ML probe response is expected to carry a lot of information – i.e., it will be providing complete information of all the APs affiliated with the AP MLD. In order to avoid frame bloating, the
spec has defined inheritance mechanism. If the information of the reported AP is the same as that of the transmitting AP, it is not duplicated in the per-STA profile of the ML IE. Without inheritance,
there will be duplication of information for each AP. This will lead to a really long response frame. Per 11ax rules, the ML probe resp sent on 6 GHz would be
sent to broadcast address (it is a recommendation for lower band). If the (broadcast) frame is sent at low MCS (for robustness), it will lead to longer air time. On the contrary, if it is sent at higher MCS,
it increases the likelihood that the frame is lost and the requester will retry. Either scenario is bad. So we need inheritance to reduce the frame size.
Could you please elaborate on the use case so that I can better understand the scenarios when the bit will be useful? Is it only useful (or intended to be used) when a non-AP MLD is retrieving critical updates information of an AP operating on another link? Regards, From: Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>
CAUTION: This email originated from outside of
the organization. Hi Laurent, Thanks for the document. I have some different thoughts on the resolution of CID #1046, #2151 and #3260. The information of the transmitting link is not always needed. E.g., if the non-AP MLD knows that the information of another link has changed, it can send a MLD probe request frame
that only solicits information of that link. So it is better to let the non-AP MLD indicate whether it needs the information on the transmitting link or not.
Best, Jason Yuchen Guo 发件人:
Cariou, Laurent [mailto:laurent.cariou@xxxxxxxxx]
Hi All, I have prepared CR doc (https://mentor.ieee.org/802.11/dcn/21/11-21-0281-00-00be-resolutions-for-cc34-cids-for-mlo-discovery-procedures-rnr.docx) which addresses several comments related to MLD discovery. Please take a look and provide your feedback? Thanks, Laurent 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 |