Hello, I have published my attempt at adding support for a Wifi sleep mode at: ...
11 years, 3 months ago
(2014-01-28 09:22:02 UTC)
#1
Hello,
I have published my attempt at adding support for a Wifi sleep mode at:
http://codereview.appspot.com/57210044
Basically, I added two new methods to the WifiPhy class:
virtual void SetSleepMode (void) = 0;
virtual void ResumeFromSleep (void) = 0;
When in sleep mode, transmitting and receiving frames is inhibited. Normal
activities are restored on resume.
The patch is against ns-3-dev, changeset 10585.
I built and tested the patch. It works as expected.
In a separate patch, I will modify WifiRadioEnergyModel so that a device is put
into sleep mode when energy is depleted.
Thanks for your attention,
Stefano
Hello, I have published my attempt at adding support for a Wifi sleep mode at: ...
11 years, 3 months ago
(2014-01-28 11:26:27 UTC)
#2
Hello,
I have published my attempt at adding support for a Wifi sleep mode at:
http://codereview.appspot.com/57210044
Basically, I added two new methods to the WifiPhy class:
virtual void SetSleepMode (void) = 0;
virtual void ResumeFromSleep (void) = 0;
When in sleep mode, transmitting and receiving frames is inhibited. Normal
activities are restored on resume.
The patch is against ns-3-dev, changeset 10585.
I built and tested the patch. It works as expected.
In a separate patch, I will modify WifiRadioEnergyModel so that a device is put
into sleep mode when energy is depleted.
Thanks for your attention,
Stefano
Hello, published a new patchset. Diffs from previous one: - added support for Wifi SLEEP ...
11 years, 3 months ago
(2014-01-29 18:00:35 UTC)
#3
Hello,
published a new patchset. Diffs from previous one:
- added support for Wifi SLEEP state in WifiRadioEnergyModel. If a depletion
callback is not set, the helper makes a callback that invokes
WifiPhy::SetSleepMode when the energy is drained
- By debugging in presence of energy sources, I found that it is better that
WifiPhy::SetSleepMode postpones the setting to sleep mode until the end of the
current reception (instead of dropping the frame)
Any comment is welcome.
Thanks,
Stefano
On 2014/01/29 18:00:35, stavallo wrote: > Hello, > > published a new patchset. Diffs from ...
11 years, 2 months ago
(2014-02-24 11:01:37 UTC)
#4
On 2014/01/29 18:00:35, stavallo wrote:
> Hello,
>
> published a new patchset. Diffs from previous one:
>
> - added support for Wifi SLEEP state in WifiRadioEnergyModel. If a depletion
> callback is not set, the helper makes a callback that invokes
> WifiPhy::SetSleepMode when the energy is drained
>
> - By debugging in presence of energy sources, I found that it is better that
> WifiPhy::SetSleepMode postpones the setting to sleep mode until the end of the
> current reception (instead of dropping the frame)
>
> Any comment is welcome.
>
> Thanks,
> Stefano
Hey Stefano,
Nice to see the patch, it is very useful for me as I am trying to implement IEEE
802.11 Power Saving Mode in NS3.
Due to your work about adding SLEEP state, have you guys ever added some codes
about PSM? I am now only change the beacon frame in ApWifiMac, add TIM field in
it and seems works well.
Bests,
Leo
This looks fine to me (I commented on one copy/paste bug) but is there a way to
provide a test or example of how energy depletion works?
Here is an example I have in mind. Create two wifi devices in ad hoc mode
within range of each other, and configure a packet generator on each one that
sends out packets infrequently (such that the radio has a chance to transition
through all of its states). Then, let the simulation run long enough so that
one of them depletes its energy reserve. Provide output that shows the energy
level decreasing over time (perhaps a log file that provides a sampling of
"timestamp energy-remaining"), and shows all state transitions (e.g. some kind
of trace sink that listens to state changes and prints out a tuple "timestamp
old-state new-state" to a log file).
In this example, there would be four log files provided, two for each device
(one for time-series of energy remaining, one for all logged state changes).
Is this an example that you or anyone else could provide to accompany this
patch?
https://codereview.appspot.com/57210044/diff/20001/src/energy/model/wifi-radi...
File src/energy/model/wifi-radio-energy-model.cc (right):
https://codereview.appspot.com/57210044/diff/20001/src/energy/model/wifi-radi...
src/energy/model/wifi-radio-energy-model.cc:198: m_switchingCurrentA =
sleepCurrentA;
this should be m_sleepCurrentA
Hi,
I'm ok with this patch, but I have one doubt. Perhaps a test could solve it.
- What happens if you call Sleep while there is a packet being transmitted ?
In particular, this is relevant when packet aggregation is enabled. I guess that
the Tx and Rx buffers will have to be cleared. don't know if this happens right
now.
By the way, together with this improvement, I'd suggest to fix also this bug:
1851: WifiRadioEnergyModel energy consumption values are taken from a 802.15.4
chip
https://www.nsnam.org/bugzilla/show_bug.cgi?id=1851
Cheers,
T.
Hello,
thanks for your review (I fixed the cut&paste typo you spotted locally, it
will be published with the next version of the patch set).
I prepared a quick example (to be improved -- suggestions are welcome) to
trace remaining energy and state changes in a simple scenario. Attached you
can find both the example script and the four log files. As you may notice,
the remaining energy decreases and when it goes to zero, the newly added
callback set the state to sleep (you don't see this in the state log file
because it would appear at the next transition -- in the example script
there are two commented lines that invoke the ResumeFromSleep method, if
uncommented you see the SLEEP state in the state log file).
Any comment is welcome.
Thanks,
Stefano
On Sat, Apr 5, 2014 at 5:57 PM, <tomh.org@gmail.com> wrote:
> This looks fine to me (I commented on one copy/paste bug) but is there a
> way to provide a test or example of how energy depletion works?
>
> Here is an example I have in mind. Create two wifi devices in ad hoc
> mode within range of each other, and configure a packet generator on
> each one that sends out packets infrequently (such that the radio has a
> chance to transition through all of its states). Then, let the
> simulation run long enough so that one of them depletes its energy
> reserve. Provide output that shows the energy level decreasing over
> time (perhaps a log file that provides a sampling of "timestamp
> energy-remaining"), and shows all state transitions (e.g. some kind of
> trace sink that listens to state changes and prints out a tuple
> "timestamp old-state new-state" to a log file).
>
> In this example, there would be four log files provided, two for each
> device (one for time-series of energy remaining, one for all logged
> state changes).
>
> Is this an example that you or anyone else could provide to accompany
> this patch?
>
>
> https://codereview.appspot.com/57210044/diff/20001/src/
> energy/model/wifi-radio-energy-model.cc
> File src/energy/model/wifi-radio-energy-model.cc (right):
>
> https://codereview.appspot.com/57210044/diff/20001/src/
> energy/model/wifi-radio-energy-model.cc#newcode198
> src/energy/model/wifi-radio-energy-model.cc:198: m_switchingCurrentA =
> sleepCurrentA;
> this should be m_sleepCurrentA
>
> https://codereview.appspot.com/57210044/
>
Hello,
thanks for your review.
On Sun, Apr 6, 2014 at 7:39 AM, <tommypec@gmail.com> wrote:
> Hi,
>
> I'm ok with this patch, but I have one doubt. Perhaps a test could solve
> it.
> - What happens if you call Sleep while there is a packet being
> transmitted ?
>
going to sleep is postponed until the end of the transmission.
> In particular, this is relevant when packet aggregation is enabled. I
> guess that the Tx and Rx buffers will have to be cleared. don't know if
> this happens right now.
>
I don't think this is done currently. I took inspiration from how switching
channels is handled. Clearly, I can modify the relevant methods of the dcf
manager if required (again, suggestions are welcome)
By the way, together with this improvement, I'd suggest to fix also this
> bug:
> 1851: WifiRadioEnergyModel energy consumption values are taken from a
> 802.15.4 chip
> https://www.nsnam.org/bugzilla/show_bug.cgi?id=1851
>
>
Sure, in the next version of the patch I will also update the current
values.
Thanks,
Stefano
> Cheers,
>
> T.
>
> https://codereview.appspot.com/57210044/
>
Hello,
anyone had a chance to look at the example script (and the logs) I provided?
Any other doubt/comment?
Thanks a lot,
Stefano
On Tue, Apr 8, 2014 at 8:01 PM, Stefano Avallone <stavallo@gmail.com> wrote:
> Hello,
>
> thanks for your review.
>
>
> On Sun, Apr 6, 2014 at 7:39 AM, <tommypec@gmail.com> wrote:
>
>> Hi,
>>
>> I'm ok with this patch, but I have one doubt. Perhaps a test could solve
>> it.
>> - What happens if you call Sleep while there is a packet being
>> transmitted ?
>>
>
> going to sleep is postponed until the end of the transmission.
>
>
>> In particular, this is relevant when packet aggregation is enabled. I
>> guess that the Tx and Rx buffers will have to be cleared. don't know if
>> this happens right now.
>>
>
> I don't think this is done currently. I took inspiration from how
> switching channels is handled. Clearly, I can modify the relevant methods
> of the dcf manager if required (again, suggestions are welcome)
>
> By the way, together with this improvement, I'd suggest to fix also this
>> bug:
>> 1851: WifiRadioEnergyModel energy consumption values are taken from a
>> 802.15.4 chip
>> https://www.nsnam.org/bugzilla/show_bug.cgi?id=1851
>>
>>
> Sure, in the next version of the patch I will also update the current
> values.
>
> Thanks,
> Stefano
>
>
>> Cheers,
>>
>> T.
>>
>> https://codereview.appspot.com/57210044/
>>
>
>
Hello,
I prepared a new patch to address bug 1851
(https://www.nsnam.org/bugzilla/show_bug.cgi?id=1851). This patch updates the
{tx, rx, idle, sleep} current values for a Wifi device and introduces a new
model (WifiTxCurrentModel) to compute the transmit current as a function of the
nominal tx power. The tx current is computed for each frame, hence this code
supports (future) wifi remote managers that perform power control.
Patch set 2 is a small code optimization I did while at it (it is useless to
pass both a wifi mode and a wifi tx vector)
Some comments on patch set 3, which is the actual work to introduce
WifiTxCurrentModel:
- the nominal tx power needs to be passed to WifiRadioEnergyModelPhyListener.
Thus txPowerDbm is passed by YansWifiPhy::SendPacket to
WifiPhyStateHelper::SwitchToTx and to WifiPhyStateHelper::NotifyTxStart. All the
PhyListeners have been updated to receive the txPowerDbm in their NotifyTxStart
method
- Besides the m_txCurrentA member, which holds the current value for the tx
current, WifiRadioEnergModel now also have a m_txCurrentModel, which is a
pointer to an object of type WifiTxCurrentModel. WifiTxCurrentModel is an
abstract base class which provides a CalcTxCurrent method, which receives the
nominal tx power and returns the tx current. A LinearWifiTxCurrentModel is
implemented, according to which the tx current linearly depends on the nominal
tx power. WifiRadioEnergyModel::SetTxCurrentFromModel (txPowerDbm) is added
which calls m_txCurrentModel->CalcTxCurrent and assigns the returned value to
m_txCurrentA. By default, m_txCurrentModel is null.
- WifiRadioEnergyModelPhyListener has a new callback, m_updateTxCurrentCallback,
which is set to WifiRadioEnergyModel::SetTxCurrentFromModel. Such a callback is
invoked from within WifiRadioEnergyModelPhyListener::NotifyTxStart
- A SetTxCurrentModel method is added to WifiRadioEnergyModelHelper to ease set
up a wifi tx current model.
I am going to send an email to the ns3-developers with an example script and the
output in different cases.
Thanks,
Stefano
Thanks for the review.
Published a new patch set, with the example added to the example/wireless
directory and the code modified to address one of the two comments. As for the
other comment, I left a reply inline with a question I have.
Regarding the request to update the documentation: I updated the documentation
of WifiRadioEnergyModel and added some explanation to WifiTxCurrentModel. I
don't know where to modify the documentation in the wifi part. Any suggestion?
Thanks,
Stefano
https://codereview.appspot.com/57210044/diff/80001/src/energy/model/wifi-radi...
File src/energy/model/wifi-radio-energy-model.cc (right):
https://codereview.appspot.com/57210044/diff/80001/src/energy/model/wifi-radi...
src/energy/model/wifi-radio-energy-model.cc:447: if
(!m_updateTxCurrentCallback.IsNull ())
Ok, in the next patch set there is the same check as the other callback. Thanks.
https://codereview.appspot.com/57210044/diff/80001/src/wifi/model/yans-wifi-p...
File src/wifi/model/yans-wifi-phy.cc (right):
https://codereview.appspot.com/57210044/diff/80001/src/wifi/model/yans-wifi-p...
src/wifi/model/yans-wifi-phy.cc:644: m_state->SwitchToTx (txDuration, packet,
GetPowerDbm (txVector.GetTxPowerLevel()), txVector, preamble);
The problem I see is that the tx vector only contains the power level. To get
the tx power in dBm we need to know the number of tx levels and the minimum and
maximum values for the tx power (in dBm). These values are stored in members of
a YansWifiPhy object. Is there a way to access those members from within
WifiPhyStateHelper::SwitchToTx?
On 2014/04/21 11:06:23, stavallo wrote:
> Thanks for the review.
>
> Published a new patch set, with the example added to the example/wireless
> directory and the code modified to address one of the two comments. As for the
> other comment, I left a reply inline with a question I have.
>
> Regarding the request to update the documentation: I updated the documentation
> of WifiRadioEnergyModel and added some explanation to WifiTxCurrentModel. I
> don't know where to modify the documentation in the wifi part. Any suggestion?
>
> Thanks,
> Stefano
>
>
https://codereview.appspot.com/57210044/diff/80001/src/energy/model/wifi-radi...
> File src/energy/model/wifi-radio-energy-model.cc (right):
>
>
https://codereview.appspot.com/57210044/diff/80001/src/energy/model/wifi-radi...
> src/energy/model/wifi-radio-energy-model.cc:447: if
> (!m_updateTxCurrentCallback.IsNull ())
> Ok, in the next patch set there is the same check as the other callback.
Thanks.
>
>
https://codereview.appspot.com/57210044/diff/80001/src/wifi/model/yans-wifi-p...
> File src/wifi/model/yans-wifi-phy.cc (right):
>
>
https://codereview.appspot.com/57210044/diff/80001/src/wifi/model/yans-wifi-p...
> src/wifi/model/yans-wifi-phy.cc:644: m_state->SwitchToTx (txDuration, packet,
> GetPowerDbm (txVector.GetTxPowerLevel()), txVector, preamble);
> The problem I see is that the tx vector only contains the power level. To get
> the tx power in dBm we need to know the number of tx levels and the minimum
and
> maximum values for the tx power (in dBm). These values are stored in members
of
> a YansWifiPhy object. Is there a way to access those members from within
> WifiPhyStateHelper::SwitchToTx?
Hi,
I see your point, I'll check later if it's possible.
About the example, one question: the WiFi radio goes into sleep ?
Also, mind uploading a "complete" patch? The last one you uploaded is a diff
against version #3.
Thanks
[apologies for the very long email]
Hello,
published an updated version of my work, which is split into three (roughly
independent) patch sets:
- #1: add support for the WIFI sleep state (includes a default callback which
puts a device in the sleep state if the energy source is depleted)
- #2: a small code optimization, which uses txVector instead of txMode and
txPower separately (not strictly required by the other patch sets)
- #3: updates the current draw values in the various wifi phy states and
introduces a model to compute the transmit current (hence the energy
consumption) as a function of the nominal TX power
With respect to the previous try, I updated the documentation (.rst files) both
in the energy part and wifi part. Also, patch set #1 includes a fix for two
issues that were disclosed by analyzing the debug info printed when running the
provided example script. I'd like to note that such issues have not been
introduced by the changes I made but are present in the current code. These
issues appear when the energy source is found to be depleted and a callback is
invoked which causes a transition in the wifi PHY state (this is why my changes
allowed to notice these issues). These issues can be explained by looking at the
debug info printed when running the provided example script (with YansWifiPhy,
WifiRadioEnergyModel and BasicEnergySource debug messages enabled):
9.156s 0 YansWifiPhy:SendPacket(0x20290f0, 0x2026a80, DsssRate11Mbps, 0, 10)
9.156s 0 WifiRadioEnergyModel:NotifyTxStart(0x2022af0, +966000.0ns)
9.156s 0 WifiRadioEnergyModel:ChangeState(0x201ee20, 2)
9.156s 0 BasicEnergySource:GetSupplyVoltage(0x2022950)
9.156s 0 BasicEnergySource:UpdateEnergySource(0x2022950)
9.156s 0 BasicEnergySource:Updating remaining energy.
9.156s 0 BasicEnergySource:CalculateRemainingEnergy(0x2022950)
9.156s 0 WifiRadioEnergyModel:DoGetCurrentA(0x201ee20)
9.156s 0 BasicEnergySource:Remaining energy = -0.00376315
9.156s 0 BasicEnergySource:HandleEnergyDrainedEvent(0x2022950)
9.156s 0 BasicEnergySource:Energy depleted!
9.156s 0 WifiRadioEnergyModel:HandleEnergyDepletion(0x201ee20)
9.156s 0 WifiRadioEnergyModel:Energy is depleted!
9.156s 0 YansWifiPhy:SetSleepMode(0x20290f0)
9.156s 0 setting sleep mode
9.156s 0 WifiRadioEnergyModel:NotifySleep(0x2022af0)
9.156s 0 WifiRadioEnergyModel:ChangeState(0x201ee20, 5)
9.156s 0 BasicEnergySource:GetSupplyVoltage(0x2022950)
9.156s 0 BasicEnergySource:UpdateEnergySource(0x2022950)
9.156s 0 BasicEnergySource:Updating remaining energy.
9.156s 0 BasicEnergySource:CalculateRemainingEnergy(0x2022950)
9.156s 0 WifiRadioEnergyModel:DoGetCurrentA(0x201ee20)
9.156s 0 BasicEnergySource:Remaining energy = -0.00875654
9.156s 0 BasicEnergySource:HandleEnergyDrainedEvent(0x2022950)
9.156s 0 BasicEnergySource:Energy depleted!
9.156s 0 WifiRadioEnergyModel:HandleEnergyDepletion(0x201ee20)
9.156s 0 WifiRadioEnergyModel:Energy is depleted!
9.156s 0 YansWifiPhy:SetSleepMode(0x20290f0)
9.156s 0 already in sleep mode
9.156s 0 WifiRadioEnergyModel:SetWifiRadioState(0x201ee20, SLEEP)
9.156s 0 WifiRadioEnergyModel:Switching to state: SLEEP at time =
+9156001999.0ns
9.156s 0 WifiRadioEnergyModel:Total energy consumption is 7.50376J
9.156s 0 WifiRadioEnergyModel:SetWifiRadioState(0x201ee20, TX)
9.156s 0 WifiRadioEnergyModel:Switching to state: TX at time = +9156001999.0ns
9.156s 0 WifiRadioEnergyModel:Total energy consumption is 7.50376J
The WifiRadioEnergyModel object is notified of a TX start and the ChangeState
callback is invoked, which calls BasicEnergySource:UpdateEnergySource. While
updating the remaining energy, the energy source is found to be depleted. The
callback (YansWifiPhy:SetSleepMode) is thus invoked, which causes a wifi phy
state transition which is notified to the WifiRadioEnergyModel object
(WifiRadioEnergyModel:NotifySleep). This in turn calls the ChangeState callback
again. Note that the previous instance of this callback is not terminated yet at
this point. The new instance of the ChangeState callback invokes
BasicEnergySource:UpdateEnergySource again.
Here we can notice the first issue: the remaining energy computed is different
than the previous value, even though the simulation time did not advance. The
reason is that in BasicEnergySource:UpdateEnergySource, m_lastUpdateTime is
updated *after* the call to HandleEnergyDrainedEvent. Hence, the second time the
remaining energy is computed, m_lastUpdateTime does not hold the updated value.
The fix for this issue is simple (found in patch set #1): move
"m_lastUpdateTime = Simulator::Now ();" before checking if the remaining energy
is less than zero. Please note that such a change does not affect the cases
where m_remainingEnergyJ is greater than zero.
After noticing that the remaining energy is (again) less than zero, the callback
YansWifiPhy:SetSleepMode is invoked again, but it has no effect since the device
is already in the sleep mode. Then, the last instance of the ChangeState
callback continues its execution and sets the wifi radio state (used by
WifiRadioEnergyModel) to SLEEP. However, at this point, the previous instance of
the ChangeState callback is resumed and sets the wifi radio state to TX. This is
clearly wrong because the current wifi phy state is SLEEP. The fix for this
second issue (found in patch set #1) aims to avoid that previous instances of
the ChangeState callback override m_currentState when they resume their
execution. This is done by tracking the number of pending change state instances
and disabling the lines of code that set m_currentState for the old instances.
Please have a look at the changes to WifiRadioEnergyModel::ChangeState in patch
set #1 (line ~262+ in src/energy/model/wifi-radio-energy-model.cc).
The debug info printed after the fix has been applied are shown in the
following:
9.156s 0 YansWifiPhy:SendPacket(0x22f60f0, 0x22f3a80, DsssRate11Mbps, 0, 10)
9.156s 0 WifiRadioEnergyModel:NotifyTxStart(0x22efaf0, +966000.0ns)
9.156s 0 WifiRadioEnergyModel:ChangeState(0x22ebe20, 2)
9.156s 0 BasicEnergySource:GetSupplyVoltage(0x22ef950)
9.156s 0 BasicEnergySource:UpdateEnergySource(0x22ef950)
9.156s 0 BasicEnergySource:Updating remaining energy.
9.156s 0 BasicEnergySource:CalculateRemainingEnergy(0x22ef950)
9.156s 0 WifiRadioEnergyModel:DoGetCurrentA(0x22ebe20)
9.156s 0 BasicEnergySource:Remaining energy = -0.00376315
9.156s 0 BasicEnergySource:HandleEnergyDrainedEvent(0x22ef950)
9.156s 0 BasicEnergySource:Energy depleted!
9.156s 0 WifiRadioEnergyModel:HandleEnergyDepletion(0x22ebe20)
9.156s 0 WifiRadioEnergyModel:Energy is depleted!
9.156s 0 YansWifiPhy:SetSleepMode(0x22f60f0)
9.156s 0 setting sleep mode
9.156s 0 WifiRadioEnergyModel:NotifySleep(0x22efaf0)
9.156s 0 WifiRadioEnergyModel:ChangeState(0x22ebe20, 5)
9.156s 0 BasicEnergySource:GetSupplyVoltage(0x22ef950)
9.156s 0 BasicEnergySource:UpdateEnergySource(0x22ef950)
9.156s 0 BasicEnergySource:Updating remaining energy.
9.156s 0 BasicEnergySource:CalculateRemainingEnergy(0x22ef950)
9.156s 0 WifiRadioEnergyModel:DoGetCurrentA(0x22ebe20)
9.156s 0 BasicEnergySource:Remaining energy = -0.00376315
9.156s 0 BasicEnergySource:HandleEnergyDrainedEvent(0x22ef950)
9.156s 0 BasicEnergySource:Energy depleted!
9.156s 0 WifiRadioEnergyModel:HandleEnergyDepletion(0x22ebe20)
9.156s 0 WifiRadioEnergyModel:Energy is depleted!
9.156s 0 YansWifiPhy:SetSleepMode(0x22f60f0)
9.156s 0 already in sleep mode
9.156s 0 WifiRadioEnergyModel:SetWifiRadioState(0x22ebe20, SLEEP)
9.156s 0 WifiRadioEnergyModel:Switching to state: SLEEP at time =
+9156001999.0ns
9.156s 0 WifiRadioEnergyModel:Total energy consumption is 7.50376J
It can be noted that the above mentioned issues have been resolved. Also, the
device is put in sleep mode and no other frames are transmitted nor received.
Any comment is welcome.
Thanks a lot for your attention,
Stefano
Issue 57210044: Add support for Wifi SLEEP mode
(Closed)
Created 11 years, 3 months ago by Stefano Avallone
Modified 9 years, 1 month ago
Reviewers: Daniel L., Tommaso Pecorella, (Tony) He Wu, Vedran Miletić, leolee0718_gmail.com, Tom Henderson
Base URL:
Comments: 5