| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Chunyu,
I have a similar question on the concept of “Latency Sensitive Link”, How to measure and decide whether a link is a latency sensitive or not? I think it comes down to two things: Channel load and OBSS congestion. As you can see, both of them are dynamic factors. That’s to say, low latency link may become non-low
latency link in some scenarios, and vice versa. For instance, if put more low latency streams on the “Latency Sensitive Link”, it may can’t meet the criteria of “Latency Sensitive” at the moment. Thanks Best Regards Jay Yang From: Dick Roy <dickroy@xxxxxxxxxxxx>
802.11 links are NOT latency sensitive. Links “have” properties such as “low latency”, however they are never sensitive to that property. Try to imagine what sensitivity
to latency would mean below layer 3! That said, the properties of such links ARE sensitive to (aka “are a function of”) external environmental factors such as load on the channel (aka congestion). That’s
why there are “priorities” … so that when necessary and appropriate, some links can “move to the head of the queue” and thereby the system can offer some form of QoS. What it appears is going on is the use of multiple links to add more capabilities to offer
QOS at some level. Instead of just using EDCA (DCF) and 4 queues of different priority, more links presumably with different EDCA parameters for each queue are added to the mix, and the AP STA has more resources to attempt to provide a level of QoS to its
STAs. It doesn’t do this over “latency sensitive links” however. It does it using multiple resources (links and queues on those links) and “intelligent” resource allocation. Naturally, if this is NOT the intent, please ignore this email :^)))) If the plan is to establish something other than a “traditional” 802.11 link (repleat w/ DCF, etc.), then give it a name that contains some identifying characteristis
of that “new link type”. Otherwise, Dmitry is probably right in suggesting that you really do not need a new name. My two cents … RR From: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
Hi, Dmitry: Good question. Yes or No. As explained in the contribution, we think it's necessary to exercise some set of management/policies and channel access rules that are different from regular traffic (versus latency sensitive traffic). Hence the differentiation among links. If we don't have such a definition, we may eventually come up with something like "a link where certain operations and configurations are conducted to optimize for latency sensitive applications" every time we need to mention such a link. The intention of the SP is to provide such a term. Please let me know if you or anyone has further questions. Thanks. Chunyu On Mon, Jun 22, 2020 at 3:17 PM Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx> wrote:
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 |