Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBN] P-EDCA open issues

Hi Mikhail, Reza, Yonggang and Dmitry

 

I have a question and a comment inline.

 

BR,

 

Xiangxin Gu

Institute of Communication Technology

unisoc-signature

 

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. 

 

[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.

[// Xiangxin Gu] A related question: what is the backoff counter after starting another P-EDCA ?

 

[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]: 

  1. 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?

[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.

  1. The problem is real: 24Mb/s RTSs are often used, NAV rules do not allow responding to an RTS until NAV expires. 
  1. The problem occurs in both UL and DL
  1. 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.

 

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

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