EDCA - TXOP

Asked by Falk on 2010-04-15

Hi,

I am wondering about the EDCA implementation.
Is it right that the TXOP element can only be configured properly for one Access Category?
Isnt it right, that 802.11n Aggregation Frames have to be send within a TXOP. Initially the txop_limit is set to 0 anyway, so one cannot simulate szenarios with streams having different AC, right?

BR,
Falk

Question information

Language:
English Edit question
Status:
Answered
For:
openWNS WiFiMAC Edit question
Assignee:
No assignee Edit question
Last query:
2010-04-15
Last reply:
2010-04-15
Sebastian Max (smx-comnets) said : #1

Hi Falk,

> I am wondering about the EDCA implementation.

Currently, there is no implementation enabling different ACs in one STA
(of course, different STAs can have different settings for
AIFS/CWmin/CWmax/TXOP length). Mixing of different ACs in one STA was
not required for us so far, hence, we did not implement it.

> Is it right that the
> TXOP element can only be configured properly for one Access Category?
Correct.

> Isnt it right, that 802.11n Aggregation Frames have to be send
> within a TXOP.
Mmm... there are no dependencies between 11n aggregation (no matter
which one) and a TXOP: As far as I understand 11n, it is possible to
send e.g. a A-MPDU without using TXOP, as long as it is protected e.g.
by a preceeding RTS/CTS.

> Initially the txop_limit is set to 0 anyway, so one
> cannot simulate szenarios with streams having different AC, right?
Close to correct. It is not possible to simulate scenarios with streams
having different ACs going through one STA.

If you want to simulate mixed traffic scenarios, it might suffice to
have two groups of STAs, configured with two different ACs.

An implementation of multiple ACs in one STA should be straight forward:
For each AC, a sub-FUN is required that contains the DCF, RTS/CTS, TXOP.
Then, a single FU acts like a demultiplexer for the sub-FUNs, with the
special functionality that internal collisions are resolved according to
the standard.

BR,
Sebastian

Harald Radke (rat-comnets) said : #2

Hello Falk,

please note, that TXOP with the current 802.11n implementation is a "little" buggy.... the problem is that TXOP asks the buffer sitting right above the BlockACK FU for the duration of the next frame. Unfortunatly the buffer doesn't know anything about aggregation further down the FUN and returns only the duration of the next unaggregated frame waiting in the queue.

To solve this a tighter coupling of the buffer with the other FUS for aggregation is needed, just like it is right now with the BlockACK (capacity <-> aggregation size)....(like traversing the FIFO buffer, using the protocol calculator to determine the aggregated size/duration of all frames to the same Rx)

I meant to fix that some time ago but simply didn't find any spare time to actually do it, especially since so far nobody used it (-;

Greez,

Harry

Can you help with this problem?

Provide an answer of your own, or ask Falk for more information if necessary.

To post a message you must log in.