Bug 627

Summary: Jakes Propagation Loss Model doesn't properly calculate signal loss
Product: ns-3 Reporter: Trevor Bosaw <bosawt>
Component: wifiAssignee: Mathieu Lacage <mathieu.lacage>
Status: RESOLVED FIXED    
Severity: normal CC: ns-bugs, tomh
Priority: P5    
Version: ns-3-dev   
Hardware: Mac Intel   
OS: Mac OS   
Attachments: simple script to set up a wifi model and print if packets are received

Description Trevor Bosaw 2009-07-07 16:25:56 UTC
Created attachment 517 [details]
simple script to set up a wifi model and print if packets are received

I'm using a simple point to point wifi setup, with a jakes propagation loss model between two nodes.  It seems that regardless of the settings I put into the loss model, the received signal is always either 'nan' or 0.  I have attached a sample script to show this behavior (logging via the terminal should be turned on).

I have also found that in the source code for the propagation loss model, if you add this print statement to the constructor:

	JakesPropagationLossModel::JakesPropagationLossModel ()
	{
		DoConstruct ();	
		printf("osc: %d, ray: %d\n",m_nOscillators,m_nRays);
	}

Both these values won't necessarily be what they should be.  (For me it says m_nOscillators is 0, and m_nRays is 3, although rays should be 1 and oscillators should be 4)  Also, in jakes-propagation-loss-model.h (lines 127-128), if the declaration of these two variables are switched.  So instead of:

			uint8_t m_nRays;	
			uint8_t m_nOscillators;		

they are switched to this:

			uint8_t m_nOscillators;	
			uint8_t m_nRays;	

Then the print statement will switch the values of the variables (so for me m_nOscillators is 3 and m_nRays is 0).
Comment 1 Trevor Bosaw 2009-07-08 14:55:48 UTC
With some testing, it appears that the error is in the DoConstruct() function placed within the constructor for JakesPropagationLossModel.  DoConstruct() uses m_nRays and m_nOscillators, neither of which has fully been instantiated at this point (valgrind shows a memory fault when Do_Construct is in the constructor, but the memory fault disappears when references to m_nRays and m_nOscillators are changed to local variables in DoConstruct)

It looks like the rest of the propagation models wait to do calculations until the DoCalcRxPower function, so perhaps move this code there?

Comment 2 Tom Henderson 2009-07-08 23:47:05 UTC
The problem is that attributes are assigned after the constructor finishes, and values are not available when DoConstruct() is called.  

Another possible solution is to schedule DoConstruct to occur at Simulator::Now() time, or to call DoConstruct from a setter function that sets the attribute m_nOscillators.

Assigning to Mathieu...
Comment 3 Mathieu Lacage 2009-07-13 03:58:25 UTC
changeset: 7555c9a0564b

please, can you verify that the bug is fixed for you ?
Comment 4 Trevor Bosaw 2009-07-13 14:46:01 UTC
Yes, it appears that the bug has been fixed.