Hi Mikhail, Reza, Yonggang and Dmitry
I have a question and a comment inline.
BR,
Xiangxin Gu
Institute of Communication Technology
From: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
Sent: Wednesday, July 9, 2025 7:13 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] P-EDCA open issues
Hi Mikhail, Reza, Yonggang, thanks you for your comments
please see below
From: Yonggang Fang <Yonggang.Fang@xxxxxxxxxxxx>
Sent: Tuesday, July 8, 2025 3:56 PM
To: Mikhail Liubogoshchev (Nokia) <mikhail.liubogoshchev@xxxxxxxxx>;
STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Cc: Reza Hedayat <reza_hedayat@xxxxxxxxx>;
Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>;
Mohamed Abouelseoud <m_abouelseoud@xxxxxxxxx>;
Liyunbo <liyunbo@xxxxxxxxxx>;
Giovanni Chisci <gchisci@xxxxxxxxxxxxxxxx>
Subject: RE: P-EDCA open issues
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>
Sent: Monday, July 7, 2025 5:42 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Cc: Reza Hedayat <reza_hedayat@xxxxxxxxx>;
Akhmetov, Dmitry <dmitry.akhmetov@xxxxxxxxx>;
Yonggang Fang <Yonggang.Fang@xxxxxxxxxxxx>;
Mohamed Abouelseoud <m_abouelseoud@xxxxxxxxx>;
Liyunbo <liyunbo@xxxxxxxxxx>;
Giovanni Chisci <gchisci@xxxxxxxxxxxxxxxx>
Subject: P-EDCA open issues
|
External email : Please do not click links or open attachments until you have verified the sender or the content. |
Hi all,
Let us continue the discussion of today’s presentation on open issues of P-EDCA in this thread.
https://mentor.ieee.org/802.11/dcn/25/11-25-0092-02-00bn-high-priority-edca-management.pptx
[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 ?
[ML] Q1: It acts according to the baseline rules, i.e., it is increased if no CTS follows the RTS.
Q2: Not sure, what is “suspend” in this context. In general, the answer is same as above: baseline rules for QSRC aren’t changed.
[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.
[ML]: sorry, that was a late-night email writing. My answer was about the backoff counter, not retry… So, just to get back on the same page:
I’m fine with the idea to keep a common backoff counter for both EDCA and P-EDCA modes.
[// Xiangxin Gu] A related question: what is the backoff counter after starting another P-EDCA ?
[ML] According to the current draft, an STA draws a new backoff counter after sending each DS.
[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]:
- That’s a valid point. However, all STAs in BSS would use same Duration value, so a chance of a collision of different DS-CTS frames isn't very high. Also, we haven’t seen any evidence that setting same scrambler sequence may improve reception at all.
[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?
[ML] I meant, if we allow configurable Duration value, different DS-CTSs can appear only in the case when there’re several OBSS with P-EDCA enabled, which are configured differently.
[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.
[ML] Yes, that’s for sure. However, the content will be the same within a BSS, and across all similarly configured BSSs, which may easily cover the majority of cases.
- The problem is real: 24Mb/s RTSs are often used, NAV rules do not allow responding to an RTS until NAV expires.
- The problem occurs in both UL and DL
- We have another degree of freedom: implementation complexity, but let me get back to the tradeoff between P-EDCA and legacy performance, and bring some illustrative results shortly.
[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.
[// Xiangxin Gu] Extra rule for UHR clients to treat NAV set by DS-CTS is non backward compatible.
[ML] Sure, we’re not striking out that option. However, indeed, that option lacks backwards compatibility and is more complicated in implementation compared to other options.
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