Low throughput when using HCF in IEEE 802.11

[dstolpmann]

Hi,
we are currently looking into using HCF/EDCA and QoS in IEEE 802.11. During our testing, we experienced that EDCA results in a far lower throughput than DCF when using only traffic that is classified as "best effort". To show this, we modified the wireless QoS showcase to include only the "best effort" traffic and disabled MSDU aggregation. The throughput over time measured at the application layer is shown in the following figure with the red plot showing the HCF/EDCA result and the blue plot showing the DCF result:

It can be seen that using HCF/EDCA results in only about 2/3 of the throughput that can be achieved with DCF. We have not found out yet where this reduction in throughput results from. One difference between both channel access methods that we found is that the AIFSN is 3 for AC_BE in HCF/EDCA and 2 in DCF. However, this seems to be only a minor difference and also changing the AIFSN for AC_BE in HCF/EDCA to 2 results in no significant change in the results.

One thing that we noticed is that using HCF/EDCA results in higher values for the NAV. However, we do not know why it is like this.

As we are unsure if this is a bug in INET or a valid difference between these two channel access methods, we hope you do not mind that we ask this question here. We appreciate any advice.

Our simulation model can be found here:
dcfvshcf.zip

[levy]

Hmm, I don't think that the larger AIFSN value is enough to explain this. The larger NAV vector mean value is suspicious. I guess due to the TxOp the channel is protected for a longer period of time. My feeling is that there may be an issue that needs to be fixed. Unfortunately, I lack the time to look into this in more detail right now. Nevertheless, thanks for reporting, I'll come back eventually.

[albert-simohartono]

Hi,
I also noticed that the NAV timer that started after receiving WlanAck is too long. So I tracked down how the NAV value gets calculated:

• NAV is equal to the duration field in the ACK
• ACK duration calculated in RecipientQosAckPolicy::computeAckDurationField() :
  duration = headerDuration - sifsTime - ackDuration
• headerDuration is the duration field in the received (to-be-acked) data packet
• the data packet duration was set in Hcf::transmitFrame() by calling singleProtectionMechanism->computeDurationField(), which in turns calls computeDataOrMgmtFrameDurationField().
• According to IEEE standard (802.11-2024 Section 9.2.5.2):

In individually addressed Data frames with an ack policy other than No Ack or Block Ack, the Duration/ID field is set to one of the following:
i) If the frame is the final frame of the TXOP, the estimated time required for the transmission of one Ack or BlockAck frame, as appropriate (including appropriate IFSs)

• For QoS data frame with best effort and background priority, the default max TXOP is 0, meaning each frame is final frame. It is implemented here:

simtime_t SingleProtectionMechanism::computeDataOrMgmtFrameDurationField()
....
    if (txop->isFinalFragment(dataOrMgmtHeader)) {
                return ackFrameDuration + modeSet->getSifsTime();
            }

However, the bool function isFinalFragment() is still unimplemented in TxopProcedure.cc.

// FIXME implement!
bool TxopProcedure::isFinalFragment(const Ptr<const Ieee80211MacHeader>& header) const
{
    return false;
}

Simply implementing this function fixes the throughput in this case (this might not cover all cases):

bool TxopProcedure::isFinalFragment(const Ptr<const Ieee80211MacHeader>& header) const
{
    if (start == -1)
        throw cRuntimeError("Txop has not started yet");
    if (limit == 0)
        return true;
    else if (!header->getMoreFragments())
        return true;
    else
        return false;
}

Note: The AIFS for best effort is set to 2 in this case, to be equal the default in DCF.

As to why the NAV / duration value was too big:
computeDataOrMgmtFrameDurationField() checks for pendingHeader when isFinalFragment is false. We always have pending header / packet because the sendInterval in app layer is higher than the actual throughput. The pending frame duration is added to our duration. At the end, it makes the NAV timer waits for too long.