veins | Veins - The open source vehicular network simulation

In my case the code was written for earlier versions of SUMO and Veins. The cc files used a different declaration of the namespace, with camel case instead of lower case. After changing to lower case the code is working without errors in Sumo 1.8 and Veins 5.1.

What you are describing are collisions: if a node receives two wireless transmissions at the same time, it has difficulties understanding either transmission. (Imagine two people speaking to you at the same time: in this situation you would also have a harder time understanding what is being said).

Normally, 802.11 tries to avoid this situation (this is the whole point of CSMA/CA, backoffs, ...), but there are cases where the mechanisms fail:

A rather well-known case is a "hidden terminal" situation, where a sender is not aware of the presence of another sender (e.g., the other sender is hidden behind a building).

Another, less well known case, is that where both senders start transmitting at the exact same time: Both senders will see that nobody else is transmitting, will change from receive to transmit mode, and will start sending (completely unaware that another sender is doing exactly this at exactly the same time). In practice, this situation is rather uncommon (after all, the two senders would need to start sending at very precisely the same time). Unfortunately, it is rather easy to do this by mistake in simulations: just configure two nodes to transmit at t=42s and they will both be trying to transmit at exactly t=42s.

I don't know if that is actually an answer to the problem or why this works. I've tried it both in my laptop (Ubuntu 18.04) and in two different virtual machines (Ubuntu 18.04 and Ubuntu 20.04) and this seems to fix the problem.

Veins should be saved in a folder called src and then imported to OMNeT++ to avoid the error. The path to Veins should be similar to the following.

In Qtenv there is no way to start simulation automatically after opening the window.

EDIT

However, based on that question you may try use xdotool to start simulation by sending F5, for example:

Because collision statistics take time to compute (essentially: trying to decode every transmission twice: once while considering interference by other nodes as usual, then trying again while ignoring all interference), Veins 5.1 requires you to explicitly turn collision statistics on. As discussed in https://stackoverflow.com/a/52103375/4707703, this can be achieved by adding a line *.**.nic.phy80211p.collectCollisionStatistics = true to omnetpp.ini.

After altering the Veins 5.1 example simulation this way and running it again (e.g., by running ./run -u Cmdenv -c Default from the command line), the ncollisions field in the resulting .sca file should now (sometimes) have non-zero values.

You can quickly verify this by running (from the command line)

AnotherNode.cc is creating a fresh mR_SA using new, but is expecting to find the sending node's mac address in there. This will not work. Rather, you would need to cast the received cMessage to this type and use member accessors to get the mac address.

The mentioned error comes from DemoBaseApplLayer::handleSelfMsg(msg). Involving this method must be done only when in your switch the matched kind is not found, i.e.:

I don't know what you are assuming is the "theoretical formula" to calculate RSSI. I am assuming you are asking about how Veins calculates received power based on transmit power of a signal. As of Veins 5.1, the calculations roughly follow a typical link budget equation, taking into account transmit power, antenna gains, as well as various loss effects. One of these is path loss; the most simple path loss model, free space path loss, is being modeled by its SimplePathlossModel: Here, the attenuation is computed as , which (for alpha=2) mirrors the formula of free space path loss.

The demo implementation of Veins 5.1 uses the OMNeT++ module ID. For more robustness, I would recommend querying the MAC layer. See, for example, https://github.com/sommer/veins/blob/veins-5.1/src/veins/modules/application/ieee80211p/DemoBaseApplLayer.cc#L83