inet-framework / inet

INET Framework for the OMNeT++ discrete event simulator
https://inet.omnetpp.org
Other
439 stars 486 forks source link

RadioMedium PathLoss not respected in DimensionalAnalogModel #634

Open fin-ger opened 3 years ago

fin-ger commented 3 years ago

I am currently trying to use the TwoRayGroundReflection path loss model in a simulation which uses an IEEE80211DimensionalRadioMedium. I realized that IPathLoss::computePathLoss gets never called in my simulation and searched for the cause of this behavior.

I found that the path loss is only called in the ScalarAnalogModelBase in line 52 whereas the DimensionalAnalogModelBase handles no path loss at all in the computeReceptionPower method.

I am wondering if this is a documentation issue, that the path loss is ignored in dimensional analog models or if this is indeed a bug.

Thanks in advance for any help!

levy commented 3 years ago

It's called in the dimensional model too but it's way more complicated than the scalar variant. The calls are here, look at FrequencyDependentAttenuationFunction, for example.

fin-ger commented 3 years ago

Ah thanks for the quick response! I'll look further into why computePathLoss is not called from there!

fin-ger commented 3 years ago

Okay, it looks like the TwoRayGroundReflection only overrides the computePathLoss(const ITransmission *transmission, const IArrival *arrival). But the power functions seem to use the computePathLoss(mps propagationSpeed, Hz frequency, m distance) which is not defined in the TwoRayGroundReflection and therefore inherited from the FreeSpacePathLoss. That's why computePathLoss is not called in the TwoRayGroundReflection.

How is the TwoRayGroundReflection supposed to be used? It is not clear to me how to setup the TwoRayGroundReflection.

fin-ger commented 3 years ago

The ScalarAnalogModel uses the (transmission, arrival) variant of computePathLoss whereas the attenuation functions always use the (mps, Hz, m) variant.

This sounds like a bug to me, although I'm unsure whether the fault is in the way attenuation functions handle path loss or the way the TwoRayGroundReflection is implemented.

levy commented 3 years ago

Hmm, the transmission/arrival variant is derived from the speed/frequency/distance variant in the base class, so subclasses are expected to override the latter method or both of them.

Therefore it seems to be a bug in the TwoRayGroundReflection pathloss, because it either should override both or override the speed/frequency/distance variant. I guess the reason is that it needs to access the PhysicalEnvironment model to determine the transmitter and receiver altitude above the ground which it clearly cannot in the other variant.

I wonder how the other pathloss functions are implemented, maybe some others are also incomplete in this sense.

levy commented 3 years ago

I'm just looking at the github web pages of the source file, so maybe I'm wrong but it seems that it's pretty straightforward to override the other variant in TwoRayGroundReflection.

fin-ger commented 3 years ago

How would you implement TwoRayGroundReflection with respect to the ground in the (mps, Hz, m) variant? I don't see how the transmitter and/or receiver altitude from the ground can be obtained.

levy commented 3 years ago

Just look at the code how it's calculating the pathloss right now. You can do the same in the other (speed/frequency/distance) variant too because the physicalEnvironment field is assigned in initialize(), so it's available. In fact, this pathloss should simply implement this other variant instead of the transmission/arrival one.

fin-ger commented 3 years ago

It seems like the altitude is obtained from the transmission and arrival position which are not available in the other variant. This means that that the ground projection must be done prior to computing the distance parameter in the attentuation functions. This is not the case, therefore the (mps, Hz, m) variant would not respect the ground model and lead to different results.

I explicitly need the ground model to be included in the path loss.

However, I still don't understand the need for 2 different computePathLoss variants, so I may be missing something here.

levy commented 3 years ago

Indeed, you're right, I missed that part. So, the reason for the other variant is that the dimensional model is capable of telling the power spectral density for all transmissions and also for the combined transmission medium at any given space-time coordinate.