| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Giovanni, I know you try to put the PTK sharing aside and make some progress on the roaming topic. But the question is the PTK sharing or not is a fundamental question for the roaming. Even I’m ok to not mention which architecture it is applied, I still have questions this SP from the technical point of view.
SP: • Do you agree that during roaming, after the request/response exchange that initiates notification of
the DS mapping change from the current AP MLD to the target AP MLD,
l
the current AP MLD is able to deliver buffered DL data frames for a TBD period of time. [Guogang Huang]It should be also allowed the current AP MLD to forward DL MSDU to the target AP MLD. And to alleviate the time-consuming
of the data forwarding, the current AP MLD may do the early data forwarding. In this case, the current AP MLD will duplicate the DL MSDU and send them to the target AP MLD.
l
The non-AP MLD may retrieve buffered DL data frames from the current AP MLD
[Guogang Huang]In this case, I don’t think the BA context is needed
in some case, e.g. all the buffered DL MSDUs are successfully delivered by the current AP MLD.
l
TBD – The non-AP MLD shall not send UL data to current AP MLD [Guogang Huang] I don’t understand this bullet. To be more precisely, I think it should be said: the current AP MLD shall not delivery
UL data through its MAC/DS SAP. Based on the same logic of the first bullet, we also need to consider to allow the UL data forwarding from the current AP MLD to the target AP MLD. We need more discussion.
l
The non-AP MLD may send UL data to target AP MLD. [Guogang Huang]I thinks it is baseline. Why do we need this bullet?
l
It is assumed that the target AP MLD is able to deliver data frames after the DS mapping change
[Guogang Huang]I thinks it is baseline. Why do we need this bullet? Supporting list: [24/0052, 24/0413, 24/0396, 23/1971, 24/0101, 23/1996, 24/0083, 24/0679] Regards 发件人: Giovanni Chisci [mailto:00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx]
Dear all, Thanks for the discussions, Pashal, Guogang, Jay, I believe that regardless of the architecture, a basic SP for the bahavior after the request/response is completed would be important to make progress. What the SP is saying
is that after request/response sequence is completed there is some time to complete delivery of pending buffered DL from current AP MLD to non-AP MLD, and during that time no UL to the current AP MLD should be sent in order to not disrupt the DS change. I
think this is quite common understanding. I am not sure where the disconnect would be, could you please elaborate on why the SP would not apply if the group decides to go with the FT approach? Thanks, Giovanni From: Peshal Nayak <p.nayak@xxxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Giovanni, Thanks for sharing the SP. I would like to echo the concerns raised by Guogang and Jay. Also, for roaming, there are a number of architectures that are currently under discussion and the proposed SP does not apply to/benefit all of them. It is important to first gain
consensus on the architecture prior to running this SP. Thanks. Peshal From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Giovanni, Thanks for preparing this SP. I have similar comment as Jay’s ones. Your SP doesn’t touch which architecture it is. And I also observe that the contribution 24/0679 from Thomas is mainly about the enhanced FT.
But the other contributions is about the roaming AP MLD. I’m a little confused about the part. Regards Guogang Huang 发件人: Jay Yang [mailto:yang.zhijie@xxxxxxxxxx]
Hi Giovanni, Thanks for the SP, I have several comments on the SP text, see them below
in blue font. Thanks Best Regards Jay Yang (杨志杰)
Original From: GiovanniChisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx> Date: 2024年05月11日
08:51 Subject: [STDS-802-11-TGBN] MAC queue for May F2F: SP on Roaming Hi Alfred, I’d like to queue the following harmonized SP for the Roaming agenda in the MAC queue SP: ·
Do you agree that during roaming, after the request/response exchange that initiates notification of the DS mapping change from the current AP MLD to the target AP MLD,
need to clarify the request/response with current AP MLD or target AP MLD? o
the current AP MLD is able to deliver buffered DL data frames for a TBD period of time. How about rewording as "the current AP MLD is able to deliver buffered DL data frames to the non-AP MLD based on certain TBD threshod(time, buffered
data numbers, etc.)" o
The non-AP MLD may retrieve buffered DL data frames from the current AP MLD
Not sure what the meaning of "retrieve" here, if it equal to receive, you can merge it to the bullet above. Otherwise, need more clarification. o
TBD – The non-AP MLD shall not send UL data to current AP MLD
When non-AP MLD receives DL data, it still have the chance to send UL data according to several contributions in preemption topic, How about rewording as "TBD--The non-AP MLD may send UL data to current AP MLD" o
The non-AP MLD may send UL data to target AP MLD.
o
It is assumed that the target AP MLD is able to deliver data frames after the DS mapping change
Add bullet: the current AP MLD is able to forward the undelived buffered DL data frames to the target AP MLD. Supporting list: [24/0052, 24/0413, 24/0396, 23/1971, 24/0101,
23/1996, 24/0083, 24/0679] These topics might have been discussed also in other contributions, so anyone please feel free to reach out to me if you’d like to add your CID and/or be included in further harmonization discussions
on this topic. Thanks, Giovanni To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1 To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1 |