| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 |