Clarifications on Wmediumd propagation model

[alexande...@gmail.com]

I had a few items I wanted to explicitly clarify regarding the propagation model-

• By default, is the Wmediumd started by Mininet-Wifi calculating error probability or using the signal_table_ieee80211ax table for calculating error probability when using a propagation model if not using 802.11n or later?
  • If using 802.11g, is a fixed bitrate equivalent to the MCS number in the same column as is implied by the commented out lines?
• The code typically yields an message saying that a range of X entails a txpower of Y, but seems to be setting a value 1 dBm lower than Y on the interface object and in the wmediumd configuration files. Is this a math quirk or is this value the actual one used?

Thanks,

Alex

[Ramon Fontes]

> By default, is the Wmediumd started by Mininet-Wifi calculating error probability or using the signal_table_ieee80211ax table for calculating error probability when using a propagation model if not using 802.11n or later?

In Mininet-WiFi with Wmediumd, the behavior is as follows:
- Wmediumd always requires a table or model to calculate the Packet
Error Rate (PER).
- If you do not specify anything, it defaults to using the built-in
signal_table_ieee80211ax.
- This means that whenever wmediumd is enabled, it does not compute
the error probability “from scratch” using only the propagation model
you selected (Friis, log-distance, etc.).
- The propagation model only provides the received signal power / SNR.
- Then, wmediumd maps this value through the table
(signal_table_ieee80211ax) to obtain the probability of success or
error.

> The code typically yields an message saying that a range of X entails a txpower of Y, but seems to be setting a value 1 dBm lower than Y on the interface object and in the wmediumd configuration files. Is this a math quirk or is this value the actual one used?

This is more of a mathematical particularity than an implementation
bug. The value shown in the log message and the value stored (1 dBm
lower) are both derived from the same calculation. The system ends up
using the stored value, so effectively, that slightly lower number is
what wmediumd and the interface object will operate with. That said,
it might deserve a closer review.

Em qua., 20 de ago. de 2025 às 15:23, alexande...@gmail.com
<alexande...@gmail.com> escreveu:

> --
> You received this message because you are subscribed to the Google Groups "mininet-wifi-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-dis...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/mininet-wifi-discuss/e9ecfbb6-2f93-45da-9977-727c99972120n%40googlegroups.com.

[alexande...@gmail.com]

Two follow-ups:

Is the SNR used for choosing the column on the table that the rate is sourced from, or is it actually informed by rate? By default, a value of -91 is set which corresponds to the 11 Mbit/s column, but the labels don't match the supported rates.

The specific behavior I'm trying to understand is that with a reported node range of ~94.1 meters (set node range=90) and the log distance propagation model (exponent is 4) for two adhoc nodes using 802.11g, the range before we hit the noise floor is consistently around 92.7 meters (I've confirmed this is what's occurring in the logs to the best of my understanding). My understanding is that, if the decimal is truncated (as seems to be implicitly occurring due to the implicit conversion when returning a float as an int https://github.com/ramonfontes/wmediumd/blob/1885687551571ae86a0a6347644950c0ea6a0e62/wmediumd/config.c#L129 ), the range should cut off at ~94 meters as reported by your code. My best guess is that there's either some sort of implicit rounding behavior or some sort of quirk on the wmediumd side that's causing some error which is skewing the path loss higher, as my attempt to re-implement the model math based on their code seemingly indicates there to not be such a large discrepancy.

-Alex

[alexande...@gmail.com]

A few follow-ups:

Is the MCS column for PER chosen based on the SNR and received power? I was potentially confused by the commented labels, but my observations would make sense if we were using the 11 Mbit/s case.

This is a larger question, but to explain what I'm trying to understand: we find consistently that two adhoc nodes using 802.11g reaches the SNR threshold (validated via wmediumd logs) for packet drop at around 92.7 meters quite consistently, despite the max range reported by your code being around ~94.1 meters. I don't think your math is incorrect; I tried re-implementing the wmediumd-side code and got a close value, especially given the result is implicitly truncated in the int casting (https://github.com/ramonfontes/wmediumd/blob/mininet-wifi/wmediumd/config.c#L129). This seems to indicate there's some sort of small error in the wmediumd side, but I've not had any luck sussing out what might be the cause. I was hoping to ask for insight or pointers to what I may check outside of the actual method?

-Alex

P.S. As far as I can tell, the higher txpower number will not yield matching results if someone tries to do the calculations manually. It would likely make sense to just report this value, unless there's some quirk in how dBm is reported typically I'm unaware of.

On Sunday, August 24, 2025 at 6:52:14 AM UTC-5 ramonre...@gmail.com wrote:

[Ramon Fontes]

> Is the SNR used for choosing the column on the table that the rate is sourced from, or is it actually informed by rate? By default, a value of -91 is set which corresponds to the 11 Mbit/s column, but the labels don't match the supported rates.

Firstly, it is important to note that the Minstrel algorithm
(implemented in the driver) is responsible for selecting the bitrate
you see via iw or iwconfig. Then,
https://github.com/ramonfontes/wmediumd/blob/mininet-wifi/wmediumd/per.c
retrieves this information from the driver and calculates the Packet
Error Rate (PER) based on the signal table defined in
https://github.com/ramonfontes/wmediumd/blob/mininet-wifi/tests/signal_table_ieee80211ax.

That said, keep in mind that in the current version wmediumd does not
yet support all Wi-Fi modes to work correctly. For more detailed
information on the available MCS rates, you may also check
mcsindex.com.

Em sex., 29 de ago. de 2025 às 10:39, alexande...@gmail.com
<alexande...@gmail.com> escreveu:

> To view this discussion visit https://groups.google.com/d/msgid/mininet-wifi-discuss/e1a7caf3-3865-488d-80c5-da7d20f848b7n%40googlegroups.com.

[alexande...@gmail.com]

My confusion stemmed primarily from getting confused by the CCA threshold getting exceeded before the noise threshold which may have been my bad, the behavior does appear correct after changing the bandwidth. Having said that, the calculation of signal strength still seems to not match my understanding of the math.

-Alex