MacRxDrop but MAC-layer ACK is sent

[Ayat]

Hello ns3ians,

There is an issue that I am facing, and I have not been able to understand its cause or find a solution.

In a WiFi network, when sending packets from the AP to several client STAs using PacketSocketClient & PacketSocketServer, and using RateErrorModel to create a high error rate (specifically 90% and 70%) at one of the client STAs, let's call it node X. As soon as corruption occurs on the first transmission of a data frame, I resend it at a low data transmission rate that I am certain will ensure the packet is received, and I prevent the error model from corrupting this retransmitted packet (this is part of an algorithm I am working on).

Initially, about a quarter of the packets reach node X. Then what happens is that the device receives the QoS data frame and sends the MAC-layer ACK frame (the function ReceiveMpdu in the QosFrameExchangeManager class is called and executed). Next, the function Receive inside the MacRxMiddle class is also called and executed. However, the callback function assigned to the trace source PacketSocketServer/Rx is not triggered. Instead, the callback of Mac/MacRxDrop is triggered. Consequently, the data frame is not raised to the upper layer, and the callback of the trace source Mac/MacRx assigned to node X is not invoked. After a period of this occurring, node X sends an association request, the association process completes, and packet transmission resumes. After some time, the previously described issue recurs: macRxDrop happens for a while, then an association request is sent, followed by an association response, and packet transmission resumes. This cycle continues, and the transmission process ends well before the simulation stopping time, with the packets that experienced macRxDrop not being delivered.

Based on what I have read, Mac/MacRxDrop is triggered when the received packet is not destined for the receiving node. However, the address is indeed the same as node X's address, and an acknowledgment is sent. I think the data frames are not retransmitted because they already acknowledged.

Based on your knowledge, experience, and expectations, are there any reasons that could cause this issue, and would addressing them resolve the problem?

Part of the code I'm using is attached to the conversation at the following link:
https://groups.google.com/g/ns-3-users/c/-4WoE-k32_k/m/ZbWb9tJcCgAJ

Your assistance in resolving this issue would be greatly appreciated.

[Ayat]

I forgot to mention the following:

1. I'm sending packets from the AP to multiple client STAs in the following sequence: first packets are sent to the first node, then to the second, and so on, and then the process repeats.
2. The mentioned problem does not occur when using a lower error rate or when sending packets to only node X instead of multiple nodes.

[Ayat]

Just bumping this up.

[Tommaso Pecorella]

Looking for a problem without a complete script is not possible, and it's quite rude to ask to figure put the missing pieces.

Said so, my best guess is that your STA gets deassociated. This is quite possible due to the humongous error rate of your setup, which can trigger the same chain of events that happens when a STA goes too far away from the AP.

Now, the questions are...

1. Why didn't you think about it? (better leave this one unanswered),
   
2. How do you prevent a STA from dissociating itself when the channel looks sh*t? (No idea, look at the code).
3. Does a channel with a 70% drop rate make sense? (with a real device no).

[Ayat]

The codebase is large and distributed across multiple files. Additionally, this work is intended for publication, so I cannot share it publicly before submission.

Regarding your questions:

1. I considered that possibility before posting my question, and it was not the issue. The STA does not disassociate.
2. There's no need to address that, as it is not the cause of the problem.
3. Unfortunately, I must implement this requirement as it is one of the project specifications.

[Tommaso Pecorella]

Well, given your constraints I'd say that we can't possibly help - and you can't possibly expect us to help you.

Now, I could try to help you, because I'm quite confident that I did find your problem. 

However, since you're working on a private project and you're not keen on sharing the relevant details, you'll understand why I'm not keen on disclosing what I do know. It's called reciprocity.

Good luck.