Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Po-kai, I don’t want to just point this to you. I just want to know what’s the exact technical reason. We do have discussed this topic for a long time. But I didn’t get any solid reason
Regards 发件人: Huang, Po-kai [mailto:po-kai.huang@xxxxxxxxx]
Hi Guogang,
I do not understand why you just point this to me. I believe when you present last time (in the minute that I cite), all the comments that are not
in favor of this direction are from other members. I am also not in favor of this direction, but I do not understand why you want to just target me on this. Best, From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Po-kai, I sent my response in the last email thread. And I didn’t get your further response any more. I can summarize
my response again. I don’t think your so-called technical issue is a real one. In order to go with Option 3, what we need to change
is just to mandatorily include a Multi-link Link Information element within the frame body for the link-specific Management frame. Otherwise, it will complicate the MLO operation. Specifically,
l
Obviously, it will complicate the encryption/decryption of the individually addressed frame
l
It will complicate the transmission of the individually addressed Management frame. Because in that case, after the MPDU Encryption, the AP MLD shall check each individually
addressed MMPDU is link-specific or not. If it is a link-specific, then the AP MLD needs to further check whether a Multi-link Link Information element is include or not. Thus the AP MLD can select a correct link to transmit this MMPDU.
l
It’s not good for the non-AP MLD’s power save. Assuming that a buffered
BU is a link-specific MMPDU and no Multi-link Link Information element is included, the target STA needs to wake up to retrieve it even there is an affiliated STA in the awake state. I really don’t know why you want complicate the MLO operation. Regards Guogang Huang 发件人: M Montemurro [mailto:montemurro.michael@xxxxxxxxx]
Hi Po-kai, Thanks for your response. I'll update CID 13599 with the text you suggest removed. For CID 12322, I could use the information from the minutes but I'd like to get feedback from others where the points from the minutes are sufficient to address a technical response. I updated a revision to the document. Cheers, Mike On Fri, Oct 7, 2022 at 4:12 PM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:
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 |