Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Question on Wi-Fi EDCA

155 views
Skip to first unread message

George Frangulea

unread,
Oct 16, 2024, 8:07:50 AM10/16/24
to ns-3-users
Hello,

I would appreciate if anyone who implements IEEE standards could clarify this for me. I want to double-check something. 

Can a Wi-Fi device transmit if AIFS is dile, without initiating the backoff procedure?

I came across references I use from  IEEE Transaction journals on mentions like this:

"The EDCA scheme works as follows. In the first transmission attempt, each station (e.g., Wi-Fi AP or device trying to initiate channel access) first senses the channel for an AIFS period and can only start transmission if the channel is sensed idle during the AIFSIf the channel is sensed busy during the AIFS, a backoff mechanism is triggered in which......"  - see paper attached


In IEEE Std 802.11-2016 Clause 10.3.2.3.6 AIFS it says that:

"A STA using the EDCAF shall obtain a TXOP for an AC if the STA’s CS mechanism (see 10.3.2.1) determines that the medium is idle at the AIFS[AC] slot boundary (see 10.22.2.4), after a correctly received frame, and the backoff timer for that AC has expired."

Thank you

Harmonious_Cross-Technology_Coexistence_With_Heterogeneous_Traffic_in_Unlicensed_Bands_Analysis_and_Approximations (1).pdf

Tom Henderson

unread,
Oct 16, 2024, 10:10:57 AM10/16/24
to ns-3-...@googlegroups.com
Many years ago we had a debate about this behavior; you can read about
it here:

https://www2.nsnam.org/bugzilla/show_bug.cgi?id=555

We resolved it in this issue:

https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2369

We decided to implement that a newly arriving frame to an empty queue
with an idle medium can immediately be sent without backoff. However, I
believe that the standard allows either behavior (perhaps intentionally).

- Tom

On 10/16/24 05:07, George Frangulea wrote:
> Hello,
>
> I would appreciate if anyone who implements IEEE standards could clarify
> this for me. I want to double-check something.
>
> Can a Wi-Fi device transmit if AIFS is dile, without initiating the
> backoff procedure?
>
> I came across references I use from  IEEE Transaction journals on
> mentions like this:
>
> "The EDCA scheme works as follows. In the first transmission attempt,
> each station (e.g., Wi-Fi AP or device trying to initiate channel
> access) *first senses the channel for an AIFS period and can only start
> transmission if the channel is sensed idle during the AIFS*. *If the
> channel is sensed busy during the AIFS, a backoff mechanism is
> triggered* in which......"  - see paper attached
>
>
> In IEEE Std 802.11-2016 Clause 10.3.2.3.6 AIFS it says that:
>
> "A STA using the EDCAF shall obtain a TXOP for an AC if the STA’s CS
> mechanism (see 10.3.2.1) *determines that the medium is idle at the
> AIFS[AC] slot boundary (see 10.22.2.4), after a correctly received
> frame, and the backoff timer for that AC has expired."*
>
> Thank you
>
> --

George Frangulea

unread,
Oct 16, 2024, 10:48:43 AM10/16/24
to ns-3-users
Hi Tom, 

I see the discussion started in 2009, at that time ETSI EN 301 893 V1.8.1 (2015-03) allowed immediate transmission, but it changed I think in 2016. 
I don't think the standard allows either behaviour or maybe we refer to different scenarios.

I am simply referring to the case where a Wi-Fi device does not have a TXOP and should initialise one. From what I know Wi-Fi standard should be in line with EN 301 893. 
As per EN 301 893 Clause 4.2.7.3.2.6, 
  • Step 3 ii) "....In case no energy within the Operating Channel is detected with a level above the ED threshold defined in clause 4.2.7.3.2.5, p may be decremented by not more than 1. If p is equal to 0, the Channel Access Engine shall proceed with step 4)"
Where step 4 is:
  • Step 4) "The Channel Access Engine shall perform a Backoff Procedure...."
You can also check the flow diagram, that there is not a direct path to go to "Equipment transmits" other than the one after the backoff procedure." Figure F.1: Flowchart for Adaptivity (Initiating Device) ".

The option to transmit if the defer period (AIFS) is idle was removed since ETSI EN 301 893 V1.8.1 (2015-03).  In this old standard you can see that immediate transmission was allowed...

If a Wi-Fi device can get a TXOP just by sensing AIFS idle it does not sound fair to me. AIFS gaps are really small. 

3GPP Type 1 CAP is in line with the same latest EN 301 893, and they do mention in TS 37.213 Section 4.1.1:
  • The eNB/gNB may transmit a transmission after first sensing the channel to be idle during the sensing slot durations of a defer duration and after the counter is zero in step 4

I attached all the mentioned documents. 
en_301893v010801p.pdf
en_301893v020101p.pdf
37213-i40.docx

Tom Henderson

unread,
Oct 16, 2024, 11:47:03 AM10/16/24
to ns-3-...@googlegroups.com, George Frangulea
George,

I wasn't aware of the ETSI conformance standards that you posted; I
previously was only looking at the IEEE standard.

The case that I cited is described further in a test in wifi-test.cc here:

https://gitlab.com/nsnam/ns-3-dev/-/blob/master/src/wifi/test/wifi-test.cc#L424

I think that in general, backoff may not be skipped, but only in a
special case (the medium has been idle for at least the AIFS and the
device has also been idle and has not been trying to perform channel
access) can it be skipped. Perhaps others who may know more can chime in.

- Tom

On 10/16/24 07:48, George Frangulea wrote:
> Hi Tom,
>
> I see the discussion started in 2009, at that time ETSI EN 301 893
> V1.8.1 (2015-03) allowed immediate transmission, but it changed I think
> in 2016.
> I don't think the standard allows either behaviour or maybe we refer to
> different scenarios.
>
> I am simply referring to the case where a Wi-Fi device does not have a
> TXOP and should initialise one. From what I know Wi-Fi standard should
> be in line with EN 301 893.
> As per EN 301 893 Clause 4.2.7.3.2.6,
>
> * Step 3 ii) "....In case no energy within the Operating Channel is
> detected with a level above the ED threshold defined in clause
> 4.2.7.3.2.5, p may be decremented by not more than 1. If p is equal
> to 0, the Channel Access Engine shall proceed with step 4)"
>
> Where step 4 is:
>
> * Step 4) "The Channel Access Engine shall perform a Backoff
> Procedure...."
>
> You can also check the flow diagram, that there is not a direct path to
> go to "Equipment transmits" other than the one after the backoff
> procedure." Figure F.1: Flowchart for Adaptivity (Initiating Device) ".
>
> The option to transmit if the defer period (AIFS) is idle was removed
> since ETSI EN 301 893 V1.8.1 (2015-03).  In this old standard you can
> see that immediate transmission was allowed...
>
> If a Wi-Fi device can get a TXOP just by sensing AIFS idle it does not
> sound fair to me. AIFS gaps are really small.
>
> 3GPP Type 1 CAP is in line with the same latest EN 301 893, and they do
> mention in TS 37.213 Section 4.1.1:
>
> * The eNB/gNB may transmit a transmission after first sensing the
> channel to be idle during the sensing slot durations of a defer
> duration *and after the counter is zero in step 4*.
> --
> Posting to this group should follow these guidelines
> https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
> <https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting>
> ---
> You received this message because you are subscribed to the Google
> Groups "ns-3-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ns-3-users+...@googlegroups.com
> <mailto:ns-3-users+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ns-3-users/749bfbcf-4169-4cc6-afd1-a81aa4b2ade2n%40googlegroups.com <https://groups.google.com/d/msgid/ns-3-users/749bfbcf-4169-4cc6-afd1-a81aa4b2ade2n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Message has been deleted
Message has been deleted
Message has been deleted

Tom Henderson

unread,
Oct 16, 2024, 3:56:35 PM10/16/24
to ns-3-...@googlegroups.com, George
I'm reposting George's latest response on his behalf, since Google
Groups does not seem to allow it to be posted.

-------- Forwarded Message --------
Subject: Re: Question on Wi-Fi EDCA
Date: Wed, 16 Oct 2024 17:39:37 +0100
From: George Frangulea <frangulea...@gmail.com>
To: Tom Henderson <to...@tomh.org>


In the code you linked it is mentioned (this is 'DCF immediate access',
Figure 9-3 of* IEEE 802.11-2012*). In 2012 the old ETSI standard still
applied.
I checked and the mentioned figure does mention this aspect " Immediate
access when maximum idle >=DIFS or AIFS[I]". However, if you check the
same figure from *IEEE 802.11-2016* this aspect is not shown anymore.

The issue might have been addressed in IEEE 802.11REVmc (2016) but my
IEEE subscription does not allow me to access these drafts. I found some
related discussion but not many details are given:
https://grouper.ieee.org/groups/802//11/email/stds-802-11/msg02011.html
<https://grouper.ieee.org/groups/802//11/email/stds-802-11/msg02011.html>

BR,
George

George Frangulea

unread,
Oct 18, 2024, 10:54:31 AM10/18/24
to ns-3-users
Hi Tom, 

At first look I see in the code you linked that it is mentioned (this is 'DCF immediate access', Figure 9-3 of IEEE 802.11-2012). In 2012 the old ETSI standard still applied. 

I checked and the mentioned figure does mention this aspect " Immediate access when maximum idle >=DIFS or AIFS[I]". However, if you check the same figure from IEEE 802.11-2016 this aspect is not shown anymore.

The issue might have been addressed in IEEE 802.11REVmc (2016) but my IEEE subscription does not allow me to access these drafts. I found some related discussion but not many details are given: https://grouper.ieee.org/groups/802//11/email/stds-802-11/msg02011.html



Message has been deleted

George Frangulea

unread,
Nov 13, 2024, 2:21:13 AM11/13/24
to ns-3-users

Hi Tom, 

Is there any way to disable such an occurrence, such as idle >=DIFS or AIFS[I], for testing? I cannot find any specific conditioning for this condition in the codes that are related to DCF, other than wifi-test.cc
Thank you!
Reply all
Reply to author
Forward
0 new messages