| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Mikhail, Reza, Yonggang, thanks you for your comments
please see below From: Yonggang Fang <Yonggang.Fang@xxxxxxxxxxxx>
Hi Mikhail, Thanks for the presentation and initiating the discussion thread. My comments are inline.
Best Regards Yonggang From: Mikhail Liubogoshchev (Nokia) <mikhail.liubogoshchev@xxxxxxxxx>
Hi all, Let us continue the discussion of today’s presentation on open issues of
P-EDCA in this thread. [Dmitry]: "for the second part (resuming backoff counter). I think the question should be set in a bit different way (i.e. broader) - do we think it is beneficial to reuse AC_VO BK counter and simply maintain
it thoughout EDCA and P-EDCA periods or isolate one from another(ie. have separate non-overlapping counters) “. [ML] Keeping one retry counter seems fine. Right now, I don’t see a case when this could lead to cheating or fairness issues. Moreover, this would greatly simplify the rules for switching between EDCA and P-EDCA
operation. [YG] “to reuse AC_VO BK counter and simply maintain it throughout EDCA and P-EDCA periods”:
Q1: does the retry counter increase after sending a RTS during P-EDCA? Q2: does the retry counter suspend if no RTS is sent in the P-EDCA ? [Akhmetov, Dmitry] May be I was not clear with my question… so far we have only one retry counter – QSRC which triggers P-EDCA. The rules to increase/reset QSRC are not changed. But we somewhat
have 2 BK (backoff) counter – one for legacy AC_VO and P-EDCA one that you count down during P-EDCA contention. I meant “may be it make sense to unify BK (backoff) counters “ In such a case transition from EDCA to P-EDCA will be seamless. [Reza]: " For the 1st part, I prefer that the duration is fixed for DS-CST (given its impact of the choice of scrambler sequence). The current spec has it fixed at 97us. It'd be good to first converge if there
is a problem before proposing a solution. Btw, does this problem occur during DL or UL case? Regarding the 2nd part, we've settled on counting each DS-CTS transmission as one P-EDCA opportunity and have set the consecutive such opportunities to be 1 (the
default value). We need to have more sim and analysis before deciding on your suggestion. Did you by any chance have such analysis e.g. the improvement for P-EDCA STAs and the impact on legacy devices?” [ML]:
[YG] Why all STAs use same Duration value, the chance of collision of different DS-CTS frames is not very high? Does it mean non
transmitting STAs could decode the collided DS-CTS? [Akhmetov, Dmitry] If choosing between 1) “lets have different content in DS-CTS” and 2) “let’s have unified (i.e. DS-CTS carrying
same content)” , (1) from the start assume that no matter what and no matter how you try to receive two different frames, the content at the receiver will have errors. I think it is obvious.
[Akhmetov, Dmitry] In the presentation you mentioned another option, like “lets make extra rules for UHR clients to treat NAV set
by DS-CTS” in a different way. I think we should not strike this option out. Thanks Mikhail Liubogoshchev 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 |