Hi Jonas,
Thanks for asking. Very good question.
You understanding is correct. An EHT AP uses traffic identifier(resource reservation mode) to tell EHT non-APs which type of low latency traffic
is allowed to use reserved resources.
I give an example design of the new element in P27 and some example values of Resource reservation Mode field as below figures. Actually we can further
define different rules for different low latency traffics. For example
−
non-APs shall stop transmitting when the value of traffic identifier is 0.
−
Non-APs should stop transmitting when the value of traffic identifier is 1.
−
Non-APs may stop transmitting when the value of traffic identifier is 2 and AP should not include Quiet element for latency purpose
Regarding your questions, I think an EHT non-AP can know AP’s intention by reading the values of traffic identifier in the new defined element. While,
legacy STAs would treat all quiet elements as for channel sensing and keep silent during quiet times.
Hope that address your concerns, please let me know if you have further comments and/or questions
Regards
Boyce
发件人: Jonas Sedin [mailto:jonas.sedin@xxxxxxxxxxxx]
发送时间: 2020年10月28日
17:40
收件人: Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: 11-20/1355 discussion
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>
Sent: den 27 oktober 2020 04:46
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: 11-20/1355 discussion
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]
发送时间: 2020年10月26日
23:40
收件人: Yangbo (Boyce,
2012 NT Lab) <yangbo59@xxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: 11-20/1355
discussion
Hello Boyce,
Thanks for your presentation. I have the following questions:
-
It seems to me that you are considering NSEP traffic as similar to LL traffic? Am I correct?
[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.
-
Is the goal to define separate TIDs for these traffic types?
[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.
-
Will the resource reservation/protected resource be enabled only during congestion or during the time non-AP MLD generates the LL traffic
even if there is no congestion or after successful association?
[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>
Sent: Monday, October 19, 2020 1:04 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [EXTERNAL] [STDS-802-11-TGBE] 11-20/1355 discussion
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
--------------------------------------------------
杨博 Yang Bo
Mobile: +86-13776629531
Email: yangbo59@xxxxxxxxxx
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