Bugzilla – Bug 1774
wpan-spectrum-propagation-loss Not assigned to a particular propagation model
Last modified: 2015-02-02 01:26:17 EST
Created attachment 1684 [details] a new wpan-spectrum-propagation-loss model proposal 1.wpan-spectrum-propagation-loss-model does not assign a particular propagation model. Utilizing the "CalculateLossFromSimpleLossModel" function from the base class "PropagationLossModel" is useless. Here I initialized a FriisPropagationLossModel object. 2.Also,without central frequency of each frequency sub-band, spectrum channel makes no sense. So the parameter freq_center is introduced to calculate the loss at each sub-band's scale.
(In reply to Liang Huo from comment #0) > Created attachment 1684 [details] > a new wpan-spectrum-propagation-loss model proposal > > 1.wpan-spectrum-propagation-loss-model does not assign a particular > propagation model. Utilizing the "CalculateLossFromSimpleLossModel" function > from the base class "PropagationLossModel" is useless. Here I initialized a > FriisPropagationLossModel object. The existing class follows the pattern introduced by SingleModelSpectrumChannel (from src/spectrum) in which the loss model is explicitly added by the user, and a default one is not provided. See examples/lr-wpan-data.cc for sample usage. So, I lean slightly against providing this suggested default loss model. > > 2.Also,without central frequency of each frequency sub-band, spectrum > channel makes no sense. So the parameter freq_center is introduced to > calculate the loss at each sub-band's scale. In a simple loss model, we just need to set the center frequency. Another approach, however, rather than passing it into this method is to have the user configure this loss model before passing it into the SingleModelSpectrumChannel. So, I don't think a change is necessary here, but in the examples/lr-wpan-data.cc, there is an error of omission of setting the correct frequency on the loss model. Also, I did not see SetLambda() as a public method of the Friis model. + Friis->SetLambda(300000000.0/f_center); but SetFrequency() would work ('Frequency' is an attribute of that class).
Followup to this enhancement. The current LrWpan helper adds a default propagation loss model: LogDistancePropagationLossModel. The point is: 1) it is not possible to change it, or to add a chained propagation loss model. 2) it is not possible (yet) to add a PropagationDelayModel [i..e, the packets are received with zero delay].
Created attachment 1894 [details] multimodel patch This patch adds the following: 1) multimodel channel 2) Set/Get channel capability 3) minor fixes and enhancements.
Created attachment 1895 [details] multimodel patch
(In reply to Tommaso Pecorella from comment #4) > Created attachment 1895 [details] > multimodel patch I could not get this patch to compile on ns-3-dev due to the helper trying to create an instance of PropagationDelayModel: ./ns3/object.h:526:37: error: cannot allocate an object of abstract type ‘ns3::PropagationDelayModel’ what did you intend to include by default?
Created attachment 1966 [details] real multimodel patch The old one wasn't the "right" one. Sorry...
(In reply to Tommaso Pecorella from comment #6) > Created attachment 1966 [details] > real multimodel patch > > The old one wasn't the "right" one. Sorry... This patch is addressing two issues: 1) LrWpanHelper is limited to SingleModelSpectrumChannel, associates LogDistancePropagationLossModel to the channel (without ability of user to change this type), and does not allow for PropagationDelayModel to be added. 2) changes to how power is computed for energy detection and SINR computation in the LrWpanPhy. It seems to me that these are unrelated and that we should open a separate issue for 2) and get others involved in confirming this aspect of the model. So, I'm inclined to split this patch and accept the portions for 1) now, and open new issue for 2) (for post ns-3.22 release). For 1), the Doxygen for LrWpanHelper should be extended to clarify the default loss and delay models that are being added.
Created attachment 1968 [details] Multiodel + doxygen clarifications I'm against splitting for one simple reason: MultiModel will make the LrWpan bug [more] evident. The LrWpanPhy bug is affecting the way the noise is computed, and any interfering signal (even from non-overlapping channels or frequencies) is computed. With SingleModel this is limited to the case of two or more PANs on different channel numbers. It seems that nobody noticed 'til now, tho. With MultiModel I expect that the users will try to use a PAN and a microwave oven, for example, or a PAN and LTE.
(In reply to Tommaso Pecorella from comment #8) > Created attachment 1968 [details] > Multiodel + doxygen clarifications > > I'm against splitting for one simple reason: MultiModel will make the LrWpan > bug [more] evident. > > The LrWpanPhy bug is affecting the way the noise is computed, and any > interfering signal (even from non-overlapping channels or frequencies) is > computed. > > With SingleModel this is limited to the case of two or more PANs on > different channel numbers. It seems that nobody noticed 'til now, tho. > > With MultiModel I expect that the users will try to use a PAN and a > microwave oven, for example, or a PAN and LTE. I see also that the TSCH changes the code similarly. https://codereview.appspot.com/194960043/patch/1/10027 I will try to slip this into ns-3-dev before the release.
Tommaso's patch pushed in two changesets: 11204:f8f2488b08ca: fix LrWpanHelper to enable MultiModelSpectrumChannel and add a default PropagationDelayModel 11205:29b708f01eb1: compute signal power around channel, not across whole band