Bugzilla – Bug 2066
A-MPDU reception should check for successful preamble
Last modified: 2020-04-12 08:12:05 EDT
Created attachment 1970 [details] patch I noticed that MPDUs in an A-MPDU could be received even though the preamble carried by the first MPDU was not successfully decoded. I propose to add a check in YansWifiPhy, which should reject the reception of MPDUs in an A-MPDU once the preamble carried by the first MPDU is not successfully received. Check patch attached.
If no comments on this, I plan to push this in the coming days.
Created attachment 1987 [details] patch v2 Fixed issue where it wrongly resets m_preambleFirstMpduReceived flag while receiving last MPDU of a concurrent transmission (i.e. while in RX state).
Note that patch has some limitations, but they are quite acceptable: - does no support capture mode -> capture mode not yet supported in ns-3 => currently OK - could lead to bad behavior if receiving the last MPDU of a concurrent A-MPDU transmission at the exact same time the last MPDU reception starts => very low probability -> quite OK I do not see any trick to get rid of them now. Any suggestions?
(In reply to sebastien.deronne from comment #3) > Note that patch has some limitations, but they are quite acceptable: > > - does no support capture mode -> capture mode not yet supported in ns-3 => > currently OK OK > > - could lead to bad behavior if receiving the last MPDU of a concurrent > A-MPDU transmission at the exact same time the last MPDU reception starts => > very low probability -> quite OK Can you describe this case and in more detail? I didn't follow. > > > I do not see any trick to get rid of them now. > Any suggestions? Suggest to leave a comment if appropriate in the code if there needs to be a caveat pointed out.
Tom, After some discussions with Ghada, we will try to find another way to solve this issue, in order to not introduce other issues. I will try to focus on it shortly.
I have some updates for this issue. I have investigated all possible scenarios and here are my conclusions. Concerning my previous comments: - “does no support capture mode -> capture mode not yet supported in ns-3» I do not think it will be a big issue to adapt the changes to make it work with packet capture mode once implemented. - “could lead to bad behavior if receiving the last MPDU of a concurrent A-MPDU transmission at the exact same time the last MPDU reception starts“ If reception of concurrent MPDUs occurs at the same time, it will not be an issue. Indeed, the receiver will always receive MPDUs of the first incoming A-MPDU since it has been pushed to the event scheduler before the second A-MPDU. So no worries about that scenario. However, a big issue/limitation in the current Wi-Fi implementation is that the reception of the preamble is not decoupled from the reception of the MPDU. This results in two undesirable behaviors: => In the patch, we assume the preamble is successfully received if EndReceive is triggered. In reality, this does not mean the preamble is successfully received. But if we move it to EndReceive, the failure of preamble+MPDU does not mean the preamble itself was not successfully decoded. => Due to the current implementation, it may occur that we receive some MPDUs (if the SNR is improved because concurrent transmissions has stopped), whereas preamble had not been successfully received (but remember that the current implementation said it was successfully received!). I thus propose to decouple the reception of the preamble from the reception of the (first) MPDU. Thus, if EndReceive for the reception of the preamble indicates a successful reception, we can set to true a flag (i.e. m_preambleReceived). The rest of the patch will be ok once this will be implemented. I am waiting for some comments/remarks before starting to implement my proposal.
Created attachment 2029 [details] patch to decouple plcp header from plcp payload reception I refactored the current packet reception to decouple plcp header from plcp payload reception (N.B.: plcp preamble reception is not yet supported in the simulator). Furthermore, this patch should fix the a-mpdu issue when the plcp preamble/header is not received. Since it changes the overall success rate for a packet in given conditions, it breaks some regression tests: devices-mesh-dot11s-regression devices-mesh-flame-regression routing-aodv-regression I propose to rebuild the pcap files used for those tests.
committed patch in changeset 11348:ded786322135
I have a question about the conceptual model of operation. If there is a failed sync in an actual implementation, will the receiver be committed to wait until end of frame or will it move on to other frames (possibly obtaining sync on another one overlapping the failed sync one)? I think it is the latter, but this patch seems to implement the former, if I am not mistaken, because it ends up calling EndReceive() even for those frames that have earlier had a failed sync. Ben Cizdziel recently implemented a different model for frame sync that performs a sync decision (a coin flip) at the start of 'StartReceivePacket' and if the sync fails, the interference helper is not committed to the frame. The frame sync calculation is driven by some error rate tables that were simulated (by another link simulator) for AWGN and TGn model D for SISO (and there is an option for users to provide their own tables). This is done in the SpectrumWifiPhy work that we are doing; it would be nice to harmonize both of these approaches. Code is here: http://code.nsnam.org/laa/ns-3-dev-laa/rev/77e8d8d22c0f Documentation is here: http://code.nsnam.org/laa/ns-3-dev-laa/rev/9f7ac807c216
(In reply to Tom Henderson from comment #9) > I have a question about the conceptual model of operation. If there is a > failed sync in an actual implementation, will the receiver be committed to > wait until end of frame or will it move on to other frames (possibly > obtaining sync on another one overlapping the failed sync one)? I think it > is the latter, but this patch seems to implement the former, if I am not > mistaken, because it ends up calling EndReceive() even for those frames that > have earlier had a failed sync. > Yes, you are right. In real implementation, I also think that the receiver will move on to the reception of other frames and not wait for the end of the failed frame. The patch should indeed be improved to take this into account. > Ben Cizdziel recently implemented a different model for frame sync that > performs a sync decision (a coin flip) at the start of 'StartReceivePacket' > and if the sync fails, the interference helper is not committed to the > frame. The frame sync calculation is driven by some error rate tables that > were simulated (by another link simulator) for AWGN and TGn model D for SISO > (and there is an option for users to provide their own tables). This is > done in the SpectrumWifiPhy work that we are doing; it would be nice to > harmonize both of these approaches. > > Code is here: > http://code.nsnam.org/laa/ns-3-dev-laa/rev/77e8d8d22c0f > > Documentation is here: > http://code.nsnam.org/laa/ns-3-dev-laa/rev/9f7ac807c216 This approach looks interesting, I will have a look and check how I can harmonize both approaches. Note that the integration of a lookup table driven PHY model for 802.11n/ac transmissions is also a task I started one year ago and that I plan to continue once I have few time.
PHY has been highly changed since this bug was reported, the problem should no longer pop up. Moving to fixed.