Castalia's Path Loss and Wireless Channel Modeling

[Jon Szymaniak]

Thanassis, if you see this, I apologize for accidentally shooting this
post directly too you -- I didn't realize the older post I was
attempting to reply to only had a "reply to author" vs a "reply".

At any rate, I am in the process of reviewing the Castalia manual,
[1], [2], [3] (for comparison), and the code, and have questions
regarding the maxTxPower variable that Evy asked about in a previous
post, and Castalia's path loss model in general.

The WirelessChannel member variable maxTxPower is declared on line 70
of WirelessChannel.h. From what I can see, this variable is assigned
in only one line of code, and read in three lines of code (shown
below). Is this just a vestige of a previous code change, or a hook
for a future change? I only ask out of curiosity -- it's clear to me
that it has no unexpected effect on the simulation operation, being
that it is 0.0.


In [1], it is noted that although X_sigma is a random process as a
function of time, the authors do not assume a dynamic environment, and
thus it is fixed for a particular link. From what I can see, it looks
like the authors' assumption is followed in Castalia -- the path loss
between two nodes is set in WirelessChannel::initialize() (with the
additional bidirectional sigma consideration), where it remains fixed
the entire simulation. The only factors that contribute to a node
receiving a message are this path loss, and interference; no
additional noise is added to the channel. (This is done with TOSSIM
[3], and I just want to verify this.) Are these assertions/assumptions
correct?

Also with regard to X, I see that omnetpp's normal() function is used
-- is the omnetpp RNG seed with the same value when rerunning a
simualtion configuration? (i.e., will my path losses be the same each
time I run a simulation?)

As always, thank you for your time and help!
Jon Szymaniak

======= Code Snippets =======

Assignment, line 513 of WirelessChannel.cc:

513 maxTxPower = 0.0;


Read, line 192--194 of WirelessChannel.cc:
192 float distanceThreshold = d0 *
193 pow(10.0,(maxTxPower - signalDeliveryThreshold - PLd0 + 3 *
sigma) /
194 (10.0 * pathLossExponent));


Read, lines 237--240

237 if (maxTxPower - PLd - bidirectionalPathLossJitter >=
signalDeliveryThreshold) {
238 pathLoss[i].push_front(new PathLossElement(j,PLd +
bidirectionalPathLossJitter));
239 totalElements++; //keep track of pathLoss size for
reporting purposes
240 }


Read,

242 if (maxTxPower - PLd + bidirectionalPathLossJitter >=
signalDeliveryThreshold) {
243 pathLoss[j].push_front(new PathLossElement(i,PLd -
bidirectionalPathLossJitter));
244 totalElements++; //keep track of pathLoss size for
reporting purposes
245 }


====== References =======
[1] M. Zuniga and B. Krishnamachari, “Analyzing the transitional
region in low power wireless links,” 2004 First Annual IEEE
Communications Society Conference on Sensor and Ad Hoc Communications
and Networks, 2004. IEEE SECON 2004., 2004, pp. 517-526.
[2] K. Sohrabi, B. Manriquez, and G.J. Pottie, “Near ground wideband
channel measurement in 800-1000 MHz,” 1999 IEEE 49th Vehicular
Technology Conference (Cat. No.99CH36363), 1999, pp. 571-574.
[3] http://www.tinyos.net/tinyos-2.x/doc/html/tutorial/usc-topologies.html

[Athanassios Boulis]

Oops I also did not realize it when I replied. Here's the reply again:

----------

About maxTxPower:

It is no vestige, since as you can see it is used in some formulas. Don't be tricked by the value 0.0. This is expressed in dBm, which means 1mW. It could easily be any other value, it just happens that in most low power radios we are concerned with, 0dBm is the highest setting. Having said this, the way we chose to represent and code this is not the most clear or modular, it was just a quick fix. As you see the wireless channel module needs to knows the maximum TX power any radio can transmit, so it will calculate some thresholds. The wireless channel could in principle look at all radio modules and parse their parameters files to find the maximum TX power of any radio but this would be a bit messy in the code. For most practical purposes the power 0dBm is the max so we just "hardcoded" it as a quick fix. We could have made it a parameter of the channel, but we thought that it would not be very useful (it would not change much). Of course if you consider high gain antennas or directional antennas, then the TX power can be more than 0dBm, so we will need to review this part of the wirelessChannel code in the future.

About pathloss:

Yes you are correct about the path loss being fixed between two nodes throughout a simulation, and this is the model adopted by [1] and [2]. However in Castalia we have the ability to add a temporal component to this constant path loss. We do this by defining a temporalModelParametersFile. You can look at it like this: In Castalia, the *average* path loss between any specific pair of nodes remains fixed, and we have the option of affecting it with a instantaneous/temporal component.

About the RNG

Yes, if you use the same seeds, then you will get the exact same results. This includes the path losses between nodes. This is essential in simulation where we need repeatability of results. It also means you need to run your simulations with multiple seeds to get a statistical valid result (you can easily do it with Castalia's -r N switch)

I hope this helps

Cheers,

Thanassis

[Jon Szymaniak]

Hi there, I have a few more questions with regard to the RNGs and the
use of the -r switch.

It looks like that without the -r script, the same seeds are used. I
assume that it is also the case that with each consecutive run of
Castalia with -r N, the same N seeds will be used with each repetition
-- is this correct?

Is there a way to see what seeds OMNeT++ is using under the hood, as
well as specify them (i.e., modify Castalia to provide these)?

As I mentioned in another thread, I'm trying to separate my
Castalia_Trace.txt file into individual simulations, and wanted to
suffix them with the seed used for my personal reference.

Thank you,
Jon Szymaniak

On Jan 20, 6:53 pm, Athanassios Boulis

[Athanassios Boulis]

It looks like that without the -r script, the same seeds are used. I
assume that it is also the case that with each consecutive run of
Castalia with -r N, the same N seeds will be used with each repetition
-- is this correct?

 

Yes, that's correct

 

Is there a way to see what seeds OMNeT++ is using under the hood, as
well as specify them (i.e., modify Castalia to provide these)?

I am not sure about knowing what seeds OMNeT is using/choosing but I do not think it matters much. You can name the seeds _sets_ (Castalia has 11 seeds for 11 RNGs, and I assume ONMeT changes all of them each time) as s1 s2 s3... etc. You can assume with high probability that you cannot choose the same seeds if you pick them manually.

You might be able to set your seeds manually. With OMNeT 3.3 and older we used to do this:

seed-0-mt = [choose a seed]

seed-1-mt = [choose a seed]

...

seed-10-mt = [choose a seed]

There is a mapping of these 11 seeds to specific RNGs used by the modules.

With OMNeT 4.0 and later (and Castalia 3.0 and later) seeds are handled automatically. You can still find the mapping of seeds to RNGs of individual modules in Simulations/Parameters/Castalia.ini

I haven't try to set seeds manually in the new versions, but reading the OMNeT manual (http://www.omnetpp.org/doc/omnetpp41/manual/usman.html) I see it can be done. You have to use the keyword seed-set or even assign values to individual seeds. Section 8.4.3 has example.

In setting manually several individual seeds for multiple repetitions, it reveals another OMNeT feature: parallel iterators (cool!)

Hope this helps