Problem in adding AMPDU in multi-cell wifi network

[Shahwaiz]

Dear All,

I have been working on the analysis of IEEE 802.11 based densely deployed networks (I am trying to optimization MAC layer parameters in-order to improve the area throughout).

Most recently, I have tried to add AMPDU within my code so as to visualize the benefits of the proposed scheme. I have added the following code,

int setofsta=0;
    int payloadSize=1472;
    int nMpdus=2;
    for (int s=0 ; s<deployAP ; s++){            //More than 1 Ap
        std::stringstream tmpss;
        tmpss << s;

        Ssid ssid = Ssid(tmpss.str());
        mac[s].SetType("ns3::StaWifiMac", "Ssid", SsidValue(ssid), "ActiveProbing",
                BooleanValue(false));
        mac[s].SetMpduAggregatorForAc (AC_BE,"ns3::MpduStandardAggregator",
                              "MaxAmpduSize", UintegerValue (nMpdus*(payloadSize+100)));
        mac[s].SetBlockAckThresholdForAc (AC_BE, 2);

            for (int u=setofsta; u<nStaWifi+setofsta; u++){        //nStaWifi nodes
                staDevices[u] = wifi_0.Install(phy_0, mac[s], wifiStaNodes.Get(u));
            }
        setofsta=setofsta+nStaWifi;
        mac[s].SetType("ns3::ApWifiMac", "Ssid", SsidValue(ssid), "BeaconGeneration", BooleanValue(true));
        mac[s].SetMpduAggregatorForAc (AC_BE,"ns3::MpduStandardAggregator",
                              "MaxAmpduSize", UintegerValue (nMpdus*(payloadSize+100)));
        mac[s].SetBlockAckThresholdForAc (AC_BE, 2);
        apDevices[s] = wifi_0.Install(phy_0, mac[s], wifiApNode.Get(s));
        }     
where, setofsta=nStaWifi=no. of stations within a cell.
           deployAP= no. of APs

When ever I try to run my code, I get the following error,
"assert failed. cond="i != m_bAckCaches.end ()", file=../src/wifi/model/mac-low.cc, line=2408
terminate called without an active exception"

I have tried to run the code for single cell and it works. But for multiple cells, it keeps on giving this error (and few others if I change the offered load and modulation scheme).

Can anyone please help? Looking forward to your kind response.

Best Regards,
Shahwaiz

[Sebastien Deronne]

Could you post your complete simulation script?

--
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 http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Shahwaiz]

Hi,

Can anyone please help.

Best Regards,
Shahwaiz

On Friday, 24 July 2015 13:45:06 UTC+2, Shahwaiz wrote:

Thank you Sebastien for your reply.

Please find attached the simulation script (I have removed a lot of other things that I was doing and have made sure it works).

Best Regards,
Shahwaiz

[Sebastien Deronne]

I will have a look but ... I have no time for the moment.

I saw already such very strange behavior in very specific cases, and were almost unreproducible, so I could not fix it.

I will check whether your case makes it much easier to debug.

[Shahwaiz]

Thanks Sebastien,
I will be waiting for your reply.

Best Regards,
Shahwaiz

[Sebastien Deronne]

Although it is not easy to debug a script where conditions change at each run because of randomness (I haven't took the time to change it though), I found the root cause and I will open a bug in the tracker.

When a station (let's call it AP1) successfully receives a MPDU from an A-MPDU (from STA 1), but in the meantime other A-MPDU transmissions occur (from STA 2 to AP2), we observe collisions and MacLow::ReceiveError is triggered for each reception.

It is important to note that MacLow::ReceiveError is triggered at AP1 also for packets sent by STA2 (if packet is corrupted, they may not decode the originator!).

But since AP1 received at least one MPDU, it will enter this condition "if (isInAmpdu && m_receivedAtLeastOneMpdu && (ampdu.GetNoOfMpdus () == 1))" when the last MPDU from the A-MPDU sent from STA2 is received by AP1 (if last MPDU from STA1 is received before = no problem, that's why in some cases simulation does not fail...). Based on that, AP1 will (wrongly!) send a BACK to STA2. This comes from this call:

          NS_LOG_DEBUG ("last a-mpdu subframe detected/sendImmediateBlockAck from=" << hdr.GetAddr2 ());

          m_sendAckEvent = Simulator::Schedule (GetSifs (),

                                                &MacLow::SendBlockAckAfterAmpdu, this,

                                                hdr.GetQosTid (),

                                                hdr.GetAddr2 (),

                                                hdr.GetDuration (),

                                                m_currentTxVector);

 Of course, since no agreement exists between STA2 and AP1, this triggers the corresponding assert.

Is it a bit clearer or not?

I do not solve it directly but I will open a bug in the tracker, because I want to find the most "elegant" way to fix it (I see multiple solutions for this, but I need to check for the best one.)

Thanks for reporting this.

Just one tip for future debugging: try to use the same failing scenario to reproduce a bug, avoid randomness for this (How will you know that your bug is fixed? Luck can be on your side for a large number of runs...)

[Shahwaiz]

Hi Sebastien,

Thank you for your reply. Sorry for the randomness/inconvenience caused, I wanted to remove that as well but didn’t before sending you the code (got lost in the moment).
Thank you for clearing the problem for me and thank you for the tips.

Best Regards,
Shahwaiz

[Sebastien Deronne]

Maybe you could rework your script so that the issue always occur?

It would definitely help to check whether issue is fixed (once I have a patch)

[Sebastien Deronne]

Have you work on a script that triggers the bug at each run?

It should not be that hard, IMO you just need to keep the positions of the nodes where the issue is observed.

[Sebastien Deronne]

I've just delivered a change in ns-3-dev for a missing condition somewhere (changeset 11614:50d7bddfc00b), which actually silents the assert you observed.

Could you provide a feedback?