InterferenceHelper abort with concurrent multi-hop Wi-Fi flows in ns-3.46 and ns-3.47

[Tomáš N]

Hello,

I am encountering a reproducible abort in the ns-3 Wi-Fi model when simulating several concurrent UDP flows over a shared IEEE 802.11 ad hoc network.

I reproduced the issue in both:

• ns-3.46
• ns-3.47

The abort in ns-3.47 is:

aborted. cond="it == niIt->second.end()", +1033.501526475s file=.../ns-3.47/src/wifi/model/interference-helper.cc, line=465 NS_FATAL, terminating terminate called without an active exception

The corresponding code in InterferenceHelper::CalculateNoiseInterferenceW() is:

it = niIt->second.find(event->GetStartTime()); NS_ABORT_IF(it == niIt->second.end());

My understanding is that the Wi-Fi PHY is evaluating a reception event, but the corresponding interference-history entry for the event start time cannot be found.

Simulation configuration

Node positions are updated in ns-3 according to externally generated time-stamped position traces, while UDP traffic is simulated over a multi-hop IEEE 802.11n ad hoc network.Relevant configuration:

• ns-3.46 and ns-3.47
• IEEE 802.11n
• ad hoc mode
• 2.4 GHz
• 20 MHz channel
• IdealWifiManager
• all Wi-Fi devices use the same channel
• UDP payload size: 1472 bytes
• four concurrent UDP flows
• offered rate: 2 Mbit/s per flow
• one destination node
• four source nodes
• four forwarding nodes arranged into two multi-hop paths
• explicit static IPv4 host routes installed hop by hop for each predefined path
• no dynamic routing protocol

Propagation configuration:

• LogDistancePropagationLossModel
• path-loss exponent: 2.2
• reference loss: approximately 40.046 dB at 1 m
• transmission power: 30 dBm
• antenna gains: 3 dB

The aggregate offered application load is approximately 8 Mbit/s. Before the abort, the routes remain stable and packets are delivered normally. There is no obvious routing failure or link disconnection at the time of the crash.

The abort becomes more reproducible when all four flows are active and both multi-hop paths operate near each other on the same Wi-Fi channel. Changing the random seed, traffic start-time offsets, or node geometry can change whether and when the abort occurs, but does not consistently eliminate it.

The simulation uses the standard single-threaded discrete-event simulator. Node positions are updated from externally generated traces, but all packet traffic is generated by ns-3 applications. TAP devices and real-time simulation are not used.

I previously encountered a different Wi-Fi PHY assertion in a smaller test using MinstrelHtWifiManager:

NS_ASSERT failed, cond="!m_wifiPhy->m_currentEvent", file=src/wifi/model/phy-entity.cc, line=493

Changing to IdealWifiManager or ConstantRateWifiManager prevented that assertion in the smaller test. However, the later InterferenceHelper abort occurs while using IdealWifiManager.

My questions are:

1. Is this a known issue in ns-3.46 or ns-3.47?
2. Under what conditions can a reception event remain active while its entry is missing from the NiChanges container?
3. Could simultaneous or overlapping receptions with identical start or end times trigger this condition?
4. Could position updates during an active reception contribute to the issue?
5. Which logging components or internal values would be most useful for diagnosing it?
6. Is there a patch or safe workaround, or would bypassing the abort invalidate the interference calculation?

I can provide a minimal reproducer, position traces, routing configuration, and the exact ns-3 commit hashes if needed.

Thank you for any advice.

Best regards,
Tomáš