| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi All, Thank you for the discussion during the call and thank you to all the members who reached out to me and provided offline feedback on the doc.
I have posted r5 of the doc with the minor changes that were made during the call and markers for the items that need further discussions: Based on the comments made during the call, I have identified the following topics that need further discussion: 1. Increasing the max from 16 to 32. My take: The objective of sharing traffic information is to allow an AP to identify critical flows for which it needs assistance from another AP, and to help the receiving AP make
informed scheduling decisions (for example, determining to whom it should potentially share the TXOP). Allowing an AP to advertise a large number of flows places a significant burden on the receiving AP, especially because it may receive similarly large sets
of flows from every neighboring AP with which it has established a MAPC agreement. This makes it increasingly difficult for the receiving AP to meaningfully differentiate among these APs and determine which one is most in need of assistance. I had originally
proposed a maximum of 8 and increased it to 16 as a reasonable compromise. Increasing this further would dilute the efficacy of the feature. 2. Whether MAPC Flow ID should be at the MLD level My response: MAPC is fundamentally a per-link operation. Each affiliated AP independently establishes a MAPC agreement with another AP in its neighborhood that is operating on the
same channel. Additionally, we cannot assume that affiliated APs of neighboring MLDs will be operating on the same channels or bands or have that link in 'enabled' state. Furthermore, the traffic flow represented in the QoS Char IE is likely an aggregation
of multiple flows. So, the same set of flows at an AP MLD will need to be identified using different flow IDs on different links of that MLD, and on the same link different IDs for MAPC agreements with different neighboring APs on that link. To have uniform
flow IDs across multiple links, MAPC would effectively need to operate at the MLD level, with MLD having links on the same channels, identical MAPC support and negotiations, and matching TID mappings. I need to think further but even with these conditions,
it may still not function reliably and would add unnecessary complexity. 3. Discussion on using Min Data Rate and Delay Bound fields for MAPC I would appreciate input from proponents of using these fields for AP2AP/MAPC,
particularly on how the transmitting AP is expected to compute and populate these parameters, and how the receiving AP would meaningfully use this information. Regards, Abhi From: Abhishek Patil <0000297b717f2a04-dmarc-request@xxxxxxxxxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi MAPC TTT members, I have prepared the following CR document that addresses several comments related to traffic indication between APs. The proposed resolution introduces a flexible and extensible framework that allows an AP
to convey its traffic info to a peer AP. A coordinating AP can then consider such information when making decisions related to TXOP sharing (poll/invite). The framework also includes a mechanism that enables an AP to update its traffic info whenever changes
occur. Could you please review the following doc and let me know if you have any suggestions? Hi
@Alfred Asterjadhi, can you please help queue this document to the TGbn MAC agenda? Regards, Abhi 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 |