1

I started (since about one week) using veins (4.4) under omnet++ (5.0).
My current task is to let vehicles adjust their transmission range according to a specific context. I did read a lot of asked questions like these ones (and in other topics/forums):

  1. Dynamical transmission range in the ieee802.11p module

  2. Vehicles Receive Beacon Messages outside RSU Range

  3. How coverage distance and interference distance are affected by each other

  4. Maximum transmission range vs maximum interference distance

  5. Reduce the coverage area between vehicles

  6. how to set the transmission range of a node under Veins 2.0?

My Question:

How to -really- change the transmission range of just some nodes?
From the links above, I knew that the term "transmission range", technically, is related to the received power, noise,sensitivity threshold, etc. which defines the probability of reception.

Since I am new to veins (and omnet++ as well), I did few tests and I concluded the following:

  • "TraCIMobility" module can adjust the nodes' parameters (for each vehicle, there is an instance) such as the ID, speed, etc.

  • I could, also, instantiate the "Mac1609_4" (for each vehicle) and changed some of its parameters like the "txPower" during simulation run-time but it had no effect on the real communication range.

  • I could not instantiate (because it was global) the "connection manager" module which was the only responsible of (and does override) the effective communication range. this module can be configured in the ".ini" file but I want different transmission powers and most importantly "can be changed during run-time".

  • The formula to calculate the transmission range is in the attached links, I got it, but it must be a way to define or change these parameters in one of the layers (even if it is in the phy layer, i.e., something like the attached signal strength...)

Again, maybe there is some wrong ideas in what I have said, I just want to know what/how to change this transmission range.

Best regards,

Community
  • 1
  • 1
MB_7
  • 103
  • 6

2 Answers2

1

You were right to increase the mac1609_4.txPower parameter to have a node send with more power (hence, the signal being decodable further away). Note, however, that (for Veins 4.4) you will also need to increase connectionManager.pMax then, as this value is used to determine the maximum distance (away from a transmitting simulation module) that a receiving simulation module will be informed about an ongoing transmission. Any receiving simulation module further away will not be influenced by the transmission (in the sense of it being a candidate for decoding, but also in the sense of it contributing to interference).

Also note that transmissions on an (otherwise) perfectly idle channel will reach much further than transmissions on a typically-loaded channel. If you want to obtain a good measurement of how far a transmission reaches, have some nodes create interference (by transmitting broadcasts of their own), then look at how the Frame Delivery Rate (FDR) drops as distance between sender and receiver increases.

Finally, note that both 1) the noise floor and 2) the minimum power level necessary for the simulation module of a receiver to attempt decoding a frame need to be calibrated to the WLAN card you want to simulate. The values chosen in the Veins 4.4 tutorial example are very useful for demonstrating the concepts of Veins, whereas the values of more recent versions of Veins come closer to what you would expect from a "typical" WLAN card used in some of the more recent field tests. See the paper Bastian Bloessl and Aisling O'Driscoll, "A Case for Good Defaults: Pitfalls in VANET Physical Layer Simulations," Proceedings of IFIP Wireless Days Conference 2019, Manchester, UK, April 2019 for a more detailed discussion of these parameters.

Christoph Sommer
  • 6,893
  • 1
  • 17
  • 35
  • Thank you mr.Sommer for the clarification, I am getting used to understand how things are modeled/work. I was confused because of our luck in the physical-layer and signal processing knowledge (we had more focus on the different strategies and schemes that are in the higher layers, e.g., proposing algorithms, protocols, etc.) I guess I got a way (or lets say a trick) to model different transmission ranges (after I record the successfulness of received frames per distances), I will be posting it in this question topic as soon as I finish a harsh deadline. Thanks & have a great day sir. – MB_7 Mar 15 '19 at 14:29
1

I am just giving my opinion in case someone was already in my situation:

In veins (the old version that I am using is 4.4), the "connection manager" is the responsible for evaluating a "potential" exchange of packets, thus, its transmission power is almost always set to the upper-bound.

I was been confused after I changed the vehicles "Mac1609_4" transmission power and "graphically", the connection manager was still showing me that the packets are received by some far nodes which in fact was not the case, it was just evaluating whether it is properly received or not (via the formula discussed in the links above).

Thus: changing the "TxPower" of each vehicle had really an effect beside graphically (the messages were not mounted to the upper layers).

In sum, to make a transmission range aware scheme, this is what must be done:

  • In the sender node (vehicle), and similarly to the pointer "traci" which deals with the mobility features, a pointer to the "mac1609" must be created and pointed to it as follows:

In "tracidemo11p.h" add ->

#include "veins/modules/mac/ieee80211p/Mac1609_4.h"//added
#include "veins/base/utils/FindModule.h"//added

and as a protected variable in the class of "tracidemo11p" in the same ".h" file ->

        Mac1609_4* mac;//added

In "tracidemo11p.cc" add ->

    mac = FindModule<Mac1609_4*>::findSubModule(getParentModule());

now you can manipulate "mac" as in "traci", the appropriate methods are in the "modules/mac/ieee80211p/Mac1609_4.cc & .h"

for our work, the method will be:

        mac->setTxPower(10);//for example

This will have an impact on the simulation in real-time for each node instance.

It may had described it with basic concepts because I am new to omnet-veins, these was done in less than one week (and will be provided for new users as well).

I hope it will be helpful (and correct)

MB_7
  • 103
  • 6
  • Many thanks for following up with a detailed explanation. You are absolutely correct: what you are seeing graphically is an **Event** (think: "A radio has started to transmit!") being delivered from the transmitting radio to all radios that are influenced by this transmission; put another way, the animation is not showing a frame being transmitted successfully. Again, thank you for following up. Your contribution is highly appreciated! – Christoph Sommer Mar 26 '19 at 09:33
  • We (as new comers to the academic research community) have the honor to get such feed-backs and orientations. I could solve it by your points and Mr.Eckhoff's and some other researchers. I will also be contributing by what I can. Arrogance and ingratitude like what some others do is not justifiable especially in high academic levels. Thank you again for devoting your valuable time to respond to almost all members' questions, we appreciate it. All the best luck mr.Sommer and have a great day. – MB_7 Mar 27 '19 at 14:41