WiFi RTS for packet aggregation

[wxw]

Hi, 

As I run simulation with AMSDU and AMPDU, I observed that with same aggregation level (2 in my case), AMSDU triggers RTS/CTS  (rtsCtsThreshold is 2346, UDP packet size is 1500byte in my sim) but AMPDU does not.

After review the code, it is obvious that this is because the decision for RTS/CTS is made at EdcaTxopN by looking at

bool

WifiRemoteStationManager::NeedRts (Mac48Address address, const WifiMacHeader *header,

                                   Ptr<const Packet> packet)

{

  NS_LOG_FUNCTION (this << address << *header << packet);

  if (address.IsGroup ())

    {

      return false;

    }

  bool normally = (packet->GetSize () + header->GetSize () + WIFI_MAC_FCS_LENGTH) > GetRtsCtsThreshold ();

  return DoNeedRts (Lookup (address, header), packet, normally);

}

In this function,  the assumption is that there is no AMPDU, PSDU length equals MSDU (AMSDU) size + MAC header + FCS. However, according to the 802.11 spec, we should compare PSDU size with dot11RTSThreshold. In AMPDU case, this comparison should be  the total AMPDU size, which means that we need somehow first get the size of the complete AMPDU and compare it with RtsCtsThreshold before we send out the very first MPDU in the AMPDU. 

I wonder if this is a known issue and if there is any plan to fix it. 

Thanks,

Xiaowen

[Sebastien Deronne]

I think you are correct.
I checked back the standard and it should indeed consider the whole A-MPDU size.

I will check a bit further if no counter indication does exist for A-MPDU, since this would mean RTS/CTS is enabled by default for A-MPDU.
If this is indeed the expected behavior, I will start a bug in the tracker and submit a fix.

[wxw]

Thanks, Sebastien.

Please post the bug tracker number if you create one.

Xiaowen

[Sebastien Deronne]

I checked a bit and this parameters seems to have been adapted since the introduction of A-MPDU...
Here is the MIB description:

"This attribute shall indicate the number of octets in an MPDU,
below which an RTS/CTS handshake shall not be performed. An
RTS/CTS handshake shall be performed at the beginning of any
frame exchange sequence where the MPDU is of type Data or
Management, the MPDU has an individual address in the Address1
field, and the length of the MPDU is greater than
this threshold. (For additional details, refer to Table 21 in
9.7.) Setting this attribute to be larger than the maximum
MSDU size shall have the effect of turning off the RTS/CTS
handshake for frames of Data or Management type transmitted by
this STA. Setting this attribute to zero shall have the effect
of turning on the RTS/CTS handshake for all frames of Data or
Management type transmitted by this STA. The default value of
this attribute shall be 2347."

So, in my opinion the only bug we have is that the attribute a description has not been updated with the introduction of a-mpdu, and the default value should be 2347 bytes iso 2346 bytes (no idea why this was chosen this way, the commonly agreed default value is 2347!).
I will not open a bug in the tracker for this, but I will change the attribute description and default value as such.

[Sebastien Deronne]

Forget about my last comment, I was wrong: RTS threshold does apply to the PSDU, so the check you mentioned should be moved to MacLow so that it compares the threshold against the total A-MPDU size. However, the description provided in the attribute should be adapted as well. 

For the fragmentation threshold, it should be specified that it does not apply to A-MPDU (but this is already OK with the current implementation).

I will start a new bug in the tracker, the patch is ready.

[wxw]

Looking forward to the patch.

Thanks,

Xiaowen

[Sebastien Deronne]

Please refer to https://www.nsnam.org/bugzilla/show_bug.cgi?id=2271

A patch to fix the issue has been proposed.

--
Posting to this group should follow these guidelines 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.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.