| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi, all, I made changes based on members’ comment and r2 is as the link below. Please feedback to me if you have further comments.
Thanks! BRs, Frank From: Frank Hsu (徐建芳)
Hi, Jay, Sorry for the late response. In your example, if the AP intends to allocate more TXOPs to that near STA, the STA may not need to consider any other information before association. The traffic management is very implementation dependent, but as I know, not only for the clients, many ISP vendors and AP vendors need such information to do network performance analysis.
FYR BRs, Frank From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Hi Frank, In traffic schedule implementation, there is one term called “airtime fairness schedule(ATF)”, another term called “traffic allocation framework(TAF)”, where the AP decide how to schedule
the traffics for difference STAs, and it’s totally non-compete schedule strategy in trigger based UL and DL scenario. In the previous case, the “near” STAs don’t have traffic, AP has to schedule the “far” STAs to make the statistic information looks “bad”. Once one “near” unassociated STA join the AP
with AR/VR traffic, the AP could give enough TXOP for this STA, which would make the statistic information pretty good although you see the statistic information quite bad before such STA join the BSS. As 802.11 SPEC don’t standardize any traffic schedule strategy. Different AP vendor has different implementation. I don’t believe the AVG statistic information of MSDUs reflects anything. Thanks Best Regards Jay Yang From: Frank Hsu (徐建芳) <frank.hsu@xxxxxxxxxxxx>
Hi, Jay, Thanks for the response. In your example, is the average reflecting the actual condition of the BSS? When an unassociated STA joins the BSS, it has to compete with 2 STAs having a lot of traffic to transmit and their
PPDUs could be long in low MCS. Thus, the average does not provide wrong signaling. FYR BRs, Frank From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Hi Frank, Thanks for setup mail thread and have more discussion. When you say the AVG delay of MSDUs or the AVG drop ratio of MSDUs, in most case, the AVG value of all MSDUs will be tended to the AVG of MSDUs on some associated STAs with large traffic.
E.g. 10 STAs(or non-AP MLD) associates with one AP(or AP MLD), there is less traffic on 8 STAs that near to the AP, while another 2 STAs have a larger traffics but far from the AP. The results show the AVG delay and AVG ratio is very bad, but it doesn’t mean
the delay and drop ratio is higher on the other 8 STAs. If a candidate/unassociated STA see such information from the Beacon frame, then it will thought the AP is in bad state. Actually, No, the AVG value give the wrong signaling. Therefore, I’m not in flavor of the direction to provide the AVG delay or drop ratio of MSDUs from all associated STAs. But we can see the benefit of the AVG delay or drop ratio between
the AP(AP MLD) and a single STA(non-AP MLD). Thanks Best Regards Jay Yang From: Frank Hsu (徐建芳) <00001a0499b52dff-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi, all, Thanks for the discussion of the document 1216r1 during the call. Due to the limit of time, I may not respond all the comments online and in the chat window.
I would like to use the email in the reflector to have follow-up offline discussion. First, let me address the chat window comments.
[FH] There are two purposes, the first the one is to help unassociated non-AP MLD to know the overall picture of the DL latency performance and it may help them for the AP MLD selection. Second, since the link level latency report cannot count MSDUs retransmitted over other links and the dropped MSDUs. Adding the MLD level statistics, including DL latency and drop ratios completes
the report.
[FH] For unassociated non-AP MLD, they can know the DL latency performance both at the MLD and link levels if it intends to associate with the AP MLD.
For associated non-AP MLDs, it may help them to decide a better T2L mapping if they have latency sensitive traffic.
[FH] Regarding the BSS AC Access Delay element, it is designed to report access delay other than the transmit delay which contains complete information of the latency (queuing latency + channel
access latency + ack delay). Also, the element is not designed for reporting statistics at the MLD level.
Regarding the statistics report, the measurement is under negotiation between two STAs, the usage scenarios are different from the proposal.
I probably missed some comments in the chat window. Please use the thread to provide your comments. Many thanks. BRs, Frank 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 |