| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Boyce, Thank you for the nice presentation last week. The way I understand the current resource reservation proposed, is that it is an element broadcasted in the beacon that tells the 11be non-APs to not/avoid transmitting during specific slots except if the non-AP has low latency data. In your presentation it is mentioned that this could work with legacy non-APs if we utilize the Quiet element that tells other non-APs to not transmit. If the above understanding is correct, will there have to be specific rules for 11be non-APs that tell them that if they receive a Quiet element, it should be ignored if there are low latency traffic. So my question is, how can a 11be non-AP know whether the Quiet element is for silencing non-11be non-APs or for other purposes? Best, Jonas From: Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx> Hi Subir, Thanks for the questions. Please see my response inline. Please let me know if you have further comments. Regards Boyce 发件人: Das, Subir [mailto:sdas@xxxxxxxxxxxxxxxxx] Hello Boyce, Thanks for your presentation. I have the following questions:
[Boyce] Yes, I am considering NSEP traffic as a high priority traffic, which should be transmitted successfully even in extremely congested situations. It would be beneficial if AP can allocate some reserved resources for NSEP traffic in extreme cases.
[Boyce] My contribution doesn’t touch how to identify those traffic types. I am just quoting from other documents to show that there are some solutions on this issue, such as new TID. I don’t have a strong preference on that topic.
[Boyce] I assume this mechanism should be enabled only when congestion occurs. As I mentioned, EDCA and trigger based access method have good performance in most of cases. We don’t need to set up resource reservation mechanism at all times. In slide #6, you mentioned “ Channel access on reserved resources could be EDCA based or other protocols.” Does this mean that the reserved resource is shared amongst all non-AP MLDs that have the higher priority traffic? [Boyce] My basic assumption is that the traffics with same priority should be treated equally. So the resources are reserved for a specified high priority traffic. If EDCA is adopted, all STAs with this specified traffic type can use reserved resources. If Trigger scheme is adopted, AP should prioritize transmission of this specified traffic type among all non-AP STAs. If we want to further reduce collisions among STAs with this specified traffic, advanced mechanism can be adopted on reserved resources (such as slotted EDCA or restricted TWT). In slide #27, you listed several LL traffic types. I understand that these are examples, but if the channel access is EDCA-based, how do you envision that these sub-categories will be mapped to existing ACs? [Boyce]Yes, you are right. These are examples to show the flexibility of this mechanism to support multiple higher priority traffics. I think the mapping to ACs depends on how we differentiate low latency traffics from regular traffics, which is not touched in my contribution. Many other contributions are discussing that part and I am open on this issue. My initial thought is that low latency traffics should have higher priority (as we agreed in PAR) so these traffics should be mapped to AC-VO or higher ACs, If defined. (Maybe VR video traffic is an exception which should be mapped to AC-VI?, I am not sure). -Subir From: Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx> hello everyone, I just presented DCN1355r3 in MAC adhoc, which is trying to offer prioritized transmission of low latency traffic with reserved resources. I notice that Liwen, Jay, Jarkko, YoungHoon, George, Mohanmed, Subir, Dibakar and Alfred are still in the queue due to time limit. Maybe other members also have some questions and clarifications on the mechanism and/or straw polls. I'd like to start a email thread to take more questions and comments. Please let me know if you have any. Thanks Boyce Yangbo -------------------------------------------------- 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 |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature