Detected Bug

Following you can see the ns3 standard debug logs for Nakagami model:

											
  Nakagami distance=99920m, power=0.1W, resultPower=0.179078W=22.5304dBm
  Nakagami distance=80m, power=0.1W, resultPower=0.0641593W=18.0726dBm
  Nakagami distance=69.7062m, power=0.1W, resultPower=0.184986W=22.6714dBm
  Nakagami distance=100000m, power=0.1W, resultPower=0.17592W=22.4531dBm
  Nakagami distance=99920m, power=0.1W, resultPower=0.404484W=26.069dBm
  Nakagami distance=100000m, power=0.1W, resultPower=0.0149106W=11.735dBm
  Nakagami distance=80m, power=0.1W, resultPower=0.000818786W=-0.868295dBm
  Nakagami distance=106.061m, power=0.1W, resultPower=0.0285696W=14.559dBm
											
										

The values shown in the last column (W's) should be received power in dBm at the receiver. As it is clearly seen, all the results shown here seem to be independent from the distance between sender and receiver. The problem is that the default ns3 implementation for NakagamiPropagationLossModel::DoCalcRxPower method just calculates the nakagami loss component and returns the result, instead of calculating the RxPower at the receiver.

											
  double powerW = std::pow (10, (txPowerDbm - 30) / 10);
  double resultPowerW;
  unsigned int int_m = static_cast(std::floor (m));

  if (int_m == m)
    resultPowerW = m_erlangRandomVariable->GetValue (int_m, powerW / m);
  else
    resultPowerW = m_gammaRandomVariable->GetValue (m, powerW / m);

  double resultPowerDbm = 10 * std::log10 (resultPowerW) + 30;
											
										

As it has been shown in the first line of the provided code from default Nakagami model implementation in ns3, the value "30" has been used instead of a dynamic calculated path loss component based on the distance between sender and receiver.

The presented patch file is fixing the issue based on the ThreeLogDistancePropagationLossModel class. It seems that the default values of the loss component are coming from the model presented in Overhaul of IEEE 802.11 Modeling and Simulation in NS-2 by Qi Chen et al.

Update: After reporting above logs to ns3 developers, it turned out that the presented Nakagami propagation loss model is just responsible for Nakagami component of the the whole loss, and other models can (should) be used to reflect the other components, i.e. Nakagami and Three Log Distance propagation loss models:

											
  YansWifiChannelHelper wifiChannel; 
  wifiChannel.AddPropagationLoss("ns3::ThreeLogDistancePropagationLossModel");
  wifiChannel.AddPropagationLoss("ns3::NakagamiPropagationLossModel");
  											
  										

The presented patch combines these two models into one (NakagamiPropagationLossModel class). I leave the patch here, since it still can provide run time optimization for large scale simulations, but in general, above code could be used to generate same results.