Skip to first unread message
ma.m...@gmail.com
Dec 4, 2018, 10:58:00 AM12/4/18
to ns-3-users
m_switchToOffEvent is a private member variable of the WifiRadioEnergyModel class, which has the task of maintaining the state-to-off event.
Each state change in the physical layer is notified to the WifiRadioEnergyModel class through the WifiRadioEnergyModelPhyListener class, and then the WifiRadioEnergyModel class calculates the maximum time that it can continuously continue to operate in that state based on the remaining energy, and then a change-to-off event in That time is scheduled.
Clearly, for each state change, the previous event maintained in the m_switchToOffEvent should be canceled and a new event calculated based on the new state should be scheduled and stored in m_switchToOffEvent.
The main bug is that despite canceling previous events when storing a new event in the m_switchToOffEvent, the previous events are not canceled and invoke at their specified time.
The invoking of those events, which should actually be canceled, has significant consequences, such as inaccurate calculation of total energy consumption and remaining energy, because, regardless of the network conditions, the very first change of state, which is a change from IDLE to TX, leads to early OFF. It's like every device stays in the TX state after its first change until it turns off.
There are other consequences that not need to be mentioned.
These problems are clear by tracing and testing the wifi-sleep simple example.
This is not a new bug, and it has been reported both personally and by others (https://www.nsnam.org/bugzilla/show_bug.cgi?id=2987), but the developer has not responded. I personally tried to fix this, but unfortunately, I have not yet come up with the result and I decided to share with you details so that if someone is trying to help fix this bug.
best regards
Each state change in the physical layer is notified to the WifiRadioEnergyModel class through the WifiRadioEnergyModelPhyListener class, and then the WifiRadioEnergyModel class calculates the maximum time that it can continuously continue to operate in that state based on the remaining energy, and then a change-to-off event in That time is scheduled.
Clearly, for each state change, the previous event maintained in the m_switchToOffEvent should be canceled and a new event calculated based on the new state should be scheduled and stored in m_switchToOffEvent.
The main bug is that despite canceling previous events when storing a new event in the m_switchToOffEvent, the previous events are not canceled and invoke at their specified time.
The invoking of those events, which should actually be canceled, has significant consequences, such as inaccurate calculation of total energy consumption and remaining energy, because, regardless of the network conditions, the very first change of state, which is a change from IDLE to TX, leads to early OFF. It's like every device stays in the TX state after its first change until it turns off.
There are other consequences that not need to be mentioned.
These problems are clear by tracing and testing the wifi-sleep simple example.
This is not a new bug, and it has been reported both personally and by others (https://www.nsnam.org/bugzilla/show_bug.cgi?id=2987), but the developer has not responded. I personally tried to fix this, but unfortunately, I have not yet come up with the result and I decided to share with you details so that if someone is trying to help fix this bug.
best regards
Sebastien Deronne
Dec 4, 2018, 11:15:03 AM12/4/18
to ns-3-users
I already replied to bug 2987, this is not a specific wifi bug and should be moved to the corresponding module IMO.
Message has been deleted
Message has been deleted
Message has been deleted
ma.m...@gmail.com
Dec 4, 2018, 2:57:55 PM12/4/18
to ns-3-users
Hi Sebastien, yes, I know you and I followed your report in Bugzilla. Unfortunately, in my opinion this bug can be dragged from anywhere, except for the EventId or Simulator class. As we know, these two classes work properly in the rest of the cases, and this seems likely to limit the bug to the wifi module.
Sebastien Deronne
Dec 4, 2018, 3:09:30 PM12/4/18
to ns-3-users
Wifi is the only module to make use of the energy model, so this might be an explanation why you only see this issue in wifi.
Have you tried Alexander's patch?
ma.m...@gmail.com
Dec 4, 2018, 3:24:57 PM12/4/18
to ns-3-users
That's exactly why I think this bug is more than anywhere else related to the WifiRadioEnergyModel class.
Yes, of course, but does not solve the problem described.
How do you deal with this problem?
ma.m...@gmail.com
Dec 12, 2018, 5:14:06 AM12/12/18
to ns-3-users
Finally I solved this problem somewhat. There is an unnecessary loop among the EnergySource, BasicEnergySource, DeviceEnergyModel and WifiRadioEnergyModel classes.
sapna jha
Apr 30, 2019, 5:29:35 AM4/30/19
to ns-3-users
Hello MAX,
Can you please provide me your solution to the above mentioned problem. It seems Energy Consumption is independent of packet size, number of packets transmitted, number of packets received. I have simulated a network of 50 nodes broadcasting packets and using Range Propagation Loss Model. Nodes further communicate based on some conditions. I want to energy consumption at each transmitting and receiving point. But energy consumption at all instances remains same.
Any suggestion will be of great help.
Reply all
Reply to author
Forward
0 new messages