| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Akira, Thanks for your suggestion and comments. The reasons why we focusing on AC_VO and not on any low latency traffic is to limit the mechanism to only one EDCAF, not just to any that hold LL traffic.
Moreover, if we remove per your suggestion AC_VO from that initial version, it would be a departure from the motion text. For sure, we can extend it, as we have “other cases are TBD”, but for that somebody should
bring a contribution so we can start that discussion Dmitry From: Akira Kishida <0000225315dd7287-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Dmitry and all, Thank you for your tremendous efforts in realizing P-EDCA and creating PDT. I have some comments and suggestions. Please see below. I would appreciate it if you could add my name as a co-author of the PDT. I understand that P-EDCA can prioritize low-latency traffic by sending a defer signal (maybe CTS). This will improve latency characteristics, but I think
it is not limited to reducing the tail access delay for a specific Access Category. Therefore, the _expression_ of the PDT would be good not to limit the reduction of tail access delays for low latency traffic buffered to the EDCA transmit
queue for the access category of AC_VO. I suggest sentences like the one below.
"Prioritized EDCA (P-EDCA) is an enhancement of the EDCA mechanism (see 10.23.2 (HCF contention based channel access (EDCA)) that aims at improving channel
access delay characteristics for low latency traffic." Moreover, the definition of low-latency traffic should be discussed more precisely. I agree that low-latency traffic is treated as AC_VO traffic, but I
think this should not mean AC_VO traffic is always treated as low-latency traffic. Moreover, other indication types, such as TID, should be able to express low-latency traffic. Best regards, Akira From: Xiaofei Wang <00001995ce968e76-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Dmitry, Please see some suggested changes and comments.
Xiaofei Clement Wang Principal Engineer | InterDigital T: (631) 622.4028 From: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
Greetings everyone, I ran a detailed SP of HIP EDCA that presented in document 1144 a while ago. During the call I had a number of questions to which I provided answers. I also noted there were many people in a queue. I’d like to use this thread for Q&A session, please submit your question here. Below are answers to some of the questions from the call: Q: Defer signal is going to be existing MAC frame or PHY signal?
After analysis we converged to have DS as a frame, so - this is frame, CTS frame.
Q: We don’t have HiP. Can you add acronym? HIP EDCA is (Hi)gh (P)riority EDCA.
Q: Do you mean that LL traffic is treated as AC_VO traffic? We propose to use this mechanism for the traffic buffered to AC_VO queue(s) Q: what’s the primary use of initial frame? You mention the Defer Signal.
The transmission of DS frame is used to start short contention period (that obviously starts after DS transmission). Only STAs that have transmitted DS signal can use that period for contention
and transmission. The DS frame _defer_ other stations contention and establish protection for that short contention period Q:HiP EDCA is distributed mechanism. Enabling/disabling condition is missing. That should be the first condition.
We believe that this part is covered in “conditions to be sent is TBD”. If group decide to have enable/disable functionality, and AP disabled HIP EDCA - the STA will not send DS and will
not use HIP EDCA. C: e.g., CTS frame or RTS. We have to choose one or both are possible. What’s the difference? We need to chose one. Our preference is CTS frame, the “(e.g. CTS or RTS)” is to highlight that frame is something existing, it is short and it is control. C: If Defer signal is CTS then what is the intention of the SP?
The SP provides details of HIP EDCA operation. A STA, if needed (condition – TBD) may send CTS (when to send – TBD) to start short (duration is TBD) contention (parameters of contention
– TBD) for LL traffic in AC_VO (and other traffic variations – TBD). We intend to resolve this TBD in a series of follow up contributions and SPs. This is step-by-step approach - instead of resolving all TBDs or providing exact details in one huge SP would
take a lot of time and effort C: Other LL STA contend the channel during the period? Or STA transmitting Defer Signal accesses the channel? Only STAs that have transmitted DS C: Is this operation performing after Defer signal? We don’t need to mandate RTS/CTS after Defer signal in a few STA cases. Short contention performed after DS transmission. Some may see mandatory RTS/CTS as unnecessary, but our analysis show that it is beneficial to have that exchange as it significantly speed
up collision resolution. C: How can STA know that traffic is low latency traffic?
For the purpose of this mechanism and this SP – a traffic considered as LL if it is in AC_VO. There is a TBD condition in that subbulet if we want to expand this to other cases C: AP should enable this operation.
We believe this is covered in “condition to send is TBD”. We need to define when STA can send DS (and start HIP EDCA contention), the enablement can be a part of this discussion
C: synchronization issue should be discussed. Our analysis shows that even In a worst case when every overlapping DS are treated as catastrophic there is a benefit of using HIP EDCA. We are open for more discussion on that C: In seven bullet, controlled by AP meaning? That solution should have an option for an AP to distribute HIP EDCA parameters Dmitry 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
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 |