Re: [riot-devel] Dynamic radio power scaling in RIOT

[Koen Zandberg]

Hi,

On 06/27/2017 09:42 AM, Peter Kietzmann wrote:
> Hi Koen,
>
> thanks for your explanations! Are you aware of the FIT IoT-lab testbed?
>
> https://www.iot-lab.info/
>
> This should give you access to several hundred iotlab-m3 nodes which are
> equipped with an at86rf231. There is also one site with some tens of
> samr21-xpros, equipped with an at86rf233.
You just made my day, I thought they only had nodes with the at86rf231
> Would be great if you keep me/us informed about your results :-).
I should have some slides with results this friday.

Regards,
Koen
>
> Best
> Peter
>
> On 26.06.2017 12:36, Koen wrote:
>> Hi,
>>
>> For now this is all quite proof of concept. I haven't had the time to
>> measure the actual power saving.
>>
>> There are still a few problems that limit the actual power saving. The
>> way I've implemented it now, only transmit power is limited. Before a
>> transmission, the radio power is configured, and almost immediately
>> after, the transmit power is set to full power again. This way L2 ACK
>> frames are always send at full power and the power scale algorithms of
>> nodes don't affect each other. Furthermore, if I have to believe the
>> datasheets, the radio's seem to also consume comparable current when in
>> RX-mode. For now, until I've confirmed the actual power draw of the
>> radio, I think the most benefits are in the reduced transmission range
>> and thus reduced interference between nodes.
>>
>> The other limitation is that my implementation depends on the radio
>> reporting the frame retries. At least the mrf24j40 and the at86rf233
>> support this. I don't know about the kw2xrf. The other variants of the
>> at86rf2xx don't seem to support reporting the frame retries, they only
>> report whether at least an ACK was received or not.
>>
>> I don't have any plans of repeated tests in network topologies at the
>> moment, mostly because I don't have a large enough network at my
>> disposal. I'm still trying to get at least repeatable results from my
>> small setup, but random interference makes this difficult. Any proposals
>> for this are welcome. I'd love to have some larger tests on node
>> interaction here. In the future I'd like to try to have RPL minimize
>> power consumption as a route metric.>
>> The actual power scaling algorithms I've implemented are based on TCP
>> congestion control. TCP congestion control also has the goal of
>> approaching a limit where loss occurs when the limit is passed. Two
>> algorithm are implemented: A "Reno" style additive increase,
>> multiplicative decrease and a "Cubic" approach style function. As soon
>> as I have some results where I can actually compare both algorithm I'll
>> share them here.
>>
>> One of the other ideas for algorithms I've had so far was a PID kind of
>> control loop where a predefined ETX value is used as a setpoint. This
>> way a configurable amount of loss versus power saving might be achieved.
>> If somebody has a different proposal for an algorithm, I'd like to know.
>> I'm currently trying to use only ETX or other already known values
>> instead of a negotiating algorithm to keep the implementation compatible
>> with different nodes and/or operating systems.
>>
>> Regards,
>> Koen
>>
>> On 06/23/2017 09:03 AM, Peter Kietzmann wrote:
>>> Hi Koen,
>>>
>>> awesome! IMO this is interesting work and I'd like to push this forward,
>>> at least to use it myself at some point in time, though I can't promise
>>> an in-depth review so soon -> let's start polishing "later".
>>>
>>> Did you already start measurements of the actual consumption saving of a
>>> node? Do you plan to evaluate your approach in different network
>>> topologies?
>>>
>>> Cheers
>>> Peter
>>>
>>> On 22.06.2017 22:00, Koen Zandberg wrote:
 Hello,

 For a small research project as a part of my study, I did some research
 on the effectiveness of dynamic radio output scaling. The general idea
 is that to save power, the radio has to transmit at only the power
 required to reach the destination. For the research I wanted to build a
 practical setup instead of a simulation as one of the research goals.

 The setup I've build works by estimating the minimum required powered
 and using layer 2 acks (or the lack thereof) as feedback. At this point
 I have a mostly working power scaling proof of concept implemented in
 RIOT. For an example measurement: https://bergzand.net/misc/etx5.svg
 which is a measurement of a number of packets. The blue dots is an ETX
 estimation measured based on the feedback from the radio module. The Red
 line is the power configured for that packet. As visible, power is
 scaled down until a stable level is reached. Power keeps oscillating
 around this level until a lot of interference is noticed, then the power
 sweeps back up.

 The merit of this whole idea is that it should both save the node power,
 but when implemented correctly also improve 

Re: [riot-devel] Dynamic radio power scaling in RIOT

[Peter Kietzmann]

Hi Koen,

thanks for your explanations! Are you aware of the FIT IoT-lab testbed?

https://www.iot-lab.info/

This should give you access to several hundred iotlab-m3 nodes which are
equipped with an at86rf231. There is also one site with some tens of
samr21-xpros, equipped with an at86rf233.

Would be great if you keep me/us informed about your results :-).

Best
Peter

On 26.06.2017 12:36, Koen wrote:
> Hi,
> 
> For now this is all quite proof of concept. I haven't had the time to
> measure the actual power saving.
> 
> There are still a few problems that limit the actual power saving. The
> way I've implemented it now, only transmit power is limited. Before a
> transmission, the radio power is configured, and almost immediately
> after, the transmit power is set to full power again. This way L2 ACK
> frames are always send at full power and the power scale algorithms of
> nodes don't affect each other. Furthermore, if I have to believe the
> datasheets, the radio's seem to also consume comparable current when in
> RX-mode. For now, until I've confirmed the actual power draw of the
> radio, I think the most benefits are in the reduced transmission range
> and thus reduced interference between nodes.
> 
> The other limitation is that my implementation depends on the radio
> reporting the frame retries. At least the mrf24j40 and the at86rf233
> support this. I don't know about the kw2xrf. The other variants of the
> at86rf2xx don't seem to support reporting the frame retries, they only
> report whether at least an ACK was received or not.
> 
> I don't have any plans of repeated tests in network topologies at the
> moment, mostly because I don't have a large enough network at my
> disposal. I'm still trying to get at least repeatable results from my
> small setup, but random interference makes this difficult. Any proposals
> for this are welcome. I'd love to have some larger tests on node
> interaction here. In the future I'd like to try to have RPL minimize
> power consumption as a route metric.>
> The actual power scaling algorithms I've implemented are based on TCP
> congestion control. TCP congestion control also has the goal of
> approaching a limit where loss occurs when the limit is passed. Two
> algorithm are implemented: A "Reno" style additive increase,
> multiplicative decrease and a "Cubic" approach style function. As soon
> as I have some results where I can actually compare both algorithm I'll
> share them here.
> 
> One of the other ideas for algorithms I've had so far was a PID kind of
> control loop where a predefined ETX value is used as a setpoint. This
> way a configurable amount of loss versus power saving might be achieved.
> If somebody has a different proposal for an algorithm, I'd like to know.
> I'm currently trying to use only ETX or other already known values
> instead of a negotiating algorithm to keep the implementation compatible
> with different nodes and/or operating systems.
> 
> Regards,
> Koen
> 
> On 06/23/2017 09:03 AM, Peter Kietzmann wrote:
>> Hi Koen,
>>
>> awesome! IMO this is interesting work and I'd like to push this forward,
>> at least to use it myself at some point in time, though I can't promise
>> an in-depth review so soon -> let's start polishing "later".
>>
>> Did you already start measurements of the actual consumption saving of a
>> node? Do you plan to evaluate your approach in different network
>> topologies?
>>
>> Cheers
>> Peter
>>
>> On 22.06.2017 22:00, Koen Zandberg wrote:
>>> Hello,
>>>
>>> For a small research project as a part of my study, I did some research
>>> on the effectiveness of dynamic radio output scaling. The general idea
>>> is that to save power, the radio has to transmit at only the power
>>> required to reach the destination. For the research I wanted to build a
>>> practical setup instead of a simulation as one of the research goals.
>>>
>>> The setup I've build works by estimating the minimum required powered
>>> and using layer 2 acks (or the lack thereof) as feedback. At this point
>>> I have a mostly working power scaling proof of concept implemented in
>>> RIOT. For an example measurement: https://bergzand.net/misc/etx5.svg
>>> which is a measurement of a number of packets. The blue dots is an ETX
>>> estimation measured based on the feedback from the radio module. The Red
>>> line is the power configured for that packet. As visible, power is
>>> scaled down until a stable level is reached. Power keeps oscillating
>>> around this level until a lot of interference is noticed, then the power
>>> sweeps back up.
>>>
>>> The merit of this whole idea is that it should both save the node power,
>>> but when implemented correctly also improve the total throughput of the
>>> network. This last point because nodes transmit with less power, thus
>>> causing less interference with nodes further away.
>>>
>>> If there is interest in having this feature merged in mainline RIOT-os,
>>> I'm willing to work on this to make sure that the 

Re: [riot-devel] Dynamic radio power scaling in RIOT

[Koen]

Hi,

For now this is all quite proof of concept. I haven't had the time to
measure the actual power saving.

There are still a few problems that limit the actual power saving. The
way I've implemented it now, only transmit power is limited. Before a
transmission, the radio power is configured, and almost immediately
after, the transmit power is set to full power again. This way L2 ACK
frames are always send at full power and the power scale algorithms of
nodes don't affect each other. Furthermore, if I have to believe the
datasheets, the radio's seem to also consume comparable current when in
RX-mode. For now, until I've confirmed the actual power draw of the
radio, I think the most benefits are in the reduced transmission range
and thus reduced interference between nodes.

The other limitation is that my implementation depends on the radio
reporting the frame retries. At least the mrf24j40 and the at86rf233
support this. I don't know about the kw2xrf. The other variants of the
at86rf2xx don't seem to support reporting the frame retries, they only
report whether at least an ACK was received or not.

I don't have any plans of repeated tests in network topologies at the
moment, mostly because I don't have a large enough network at my
disposal. I'm still trying to get at least repeatable results from my
small setup, but random interference makes this difficult. Any proposals
for this are welcome. I'd love to have some larger tests on node
interaction here. In the future I'd like to try to have RPL minimize
power consumption as a route metric.

The actual power scaling algorithms I've implemented are based on TCP
congestion control. TCP congestion control also has the goal of
approaching a limit where loss occurs when the limit is passed. Two
algorithm are implemented: A "Reno" style additive increase,
multiplicative decrease and a "Cubic" approach style function. As soon
as I have some results where I can actually compare both algorithm I'll
share them here.

One of the other ideas for algorithms I've had so far was a PID kind of
control loop where a predefined ETX value is used as a setpoint. This
way a configurable amount of loss versus power saving might be achieved.
If somebody has a different proposal for an algorithm, I'd like to know.
I'm currently trying to use only ETX or other already known values
instead of a negotiating algorithm to keep the implementation compatible
with different nodes and/or operating systems.

Regards,
Koen

On 06/23/2017 09:03 AM, Peter Kietzmann wrote:
> Hi Koen,
>
> awesome! IMO this is interesting work and I'd like to push this forward,
> at least to use it myself at some point in time, though I can't promise
> an in-depth review so soon -> let's start polishing "later".
>
> Did you already start measurements of the actual consumption saving of a
> node? Do you plan to evaluate your approach in different network
> topologies?
>
> Cheers
> Peter
>
> On 22.06.2017 22:00, Koen Zandberg wrote:
>> Hello,
>>
>> For a small research project as a part of my study, I did some research
>> on the effectiveness of dynamic radio output scaling. The general idea
>> is that to save power, the radio has to transmit at only the power
>> required to reach the destination. For the research I wanted to build a
>> practical setup instead of a simulation as one of the research goals.
>>
>> The setup I've build works by estimating the minimum required powered
>> and using layer 2 acks (or the lack thereof) as feedback. At this point
>> I have a mostly working power scaling proof of concept implemented in
>> RIOT. For an example measurement: https://bergzand.net/misc/etx5.svg
>> which is a measurement of a number of packets. The blue dots is an ETX
>> estimation measured based on the feedback from the radio module. The Red
>> line is the power configured for that packet. As visible, power is
>> scaled down until a stable level is reached. Power keeps oscillating
>> around this level until a lot of interference is noticed, then the power
>> sweeps back up.
>>
>> The merit of this whole idea is that it should both save the node power,
>> but when implemented correctly also improve the total throughput of the
>> network. This last point because nodes transmit with less power, thus
>> causing less interference with nodes further away.
>>
>> If there is interest in having this feature merged in mainline RIOT-os,
>> I'm willing to work on this to make sure that the code quality is as
>> required. The code can be viewed and tracked at
>> https://github.com/bergzand/RIOT/tree/mwn2
>>
>> Regards,
>> Koen
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Dynamic radio power scaling in RIOT

[Joakim Nohlgård]

Hi Koen,
This sounds to me like a very promising feature for RIOT! Both the power
saving aspect as well as reducing interference for neighboring networks are
important features. Especially for urban environments it will be important
to not pollute the radio environment more than necessary when IoT devices
start becoming ubiquitous.

Best regards,
Joakim Nohlgård
Eistec AB

On Jun 22, 2017 10:00 PM, "Koen Zandberg"  wrote:

Hello,

For a small research project as a part of my study, I did some research
on the effectiveness of dynamic radio output scaling. The general idea
is that to save power, the radio has to transmit at only the power
required to reach the destination. For the research I wanted to build a
practical setup instead of a simulation as one of the research goals.

The setup I've build works by estimating the minimum required powered
and using layer 2 acks (or the lack thereof) as feedback. At this point
I have a mostly working power scaling proof of concept implemented in
RIOT. For an example measurement: https://bergzand.net/misc/etx5.svg
which is a measurement of a number of packets. The blue dots is an ETX
estimation measured based on the feedback from the radio module. The Red
line is the power configured for that packet. As visible, power is
scaled down until a stable level is reached. Power keeps oscillating
around this level until a lot of interference is noticed, then the power
sweeps back up.

The merit of this whole idea is that it should both save the node power,
but when implemented correctly also improve the total throughput of the
network. This last point because nodes transmit with less power, thus
causing less interference with nodes further away.

If there is interest in having this feature merged in mainline RIOT-os,
I'm willing to work on this to make sure that the code quality is as
required. The code can be viewed and tracked at
https://github.com/bergzand/RIOT/tree/mwn2

Regards,
Koen

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Dynamic radio power scaling in RIOT

[Peter Kietzmann]

Hi Koen,

awesome! IMO this is interesting work and I'd like to push this forward,
at least to use it myself at some point in time, though I can't promise
an in-depth review so soon -> let's start polishing "later".

Did you already start measurements of the actual consumption saving of a
node? Do you plan to evaluate your approach in different network
topologies?

Cheers
Peter

On 22.06.2017 22:00, Koen Zandberg wrote:
> Hello,
> 
> For a small research project as a part of my study, I did some research
> on the effectiveness of dynamic radio output scaling. The general idea
> is that to save power, the radio has to transmit at only the power
> required to reach the destination. For the research I wanted to build a
> practical setup instead of a simulation as one of the research goals.
> 
> The setup I've build works by estimating the minimum required powered
> and using layer 2 acks (or the lack thereof) as feedback. At this point
> I have a mostly working power scaling proof of concept implemented in
> RIOT. For an example measurement: https://bergzand.net/misc/etx5.svg
> which is a measurement of a number of packets. The blue dots is an ETX
> estimation measured based on the feedback from the radio module. The Red
> line is the power configured for that packet. As visible, power is
> scaled down until a stable level is reached. Power keeps oscillating
> around this level until a lot of interference is noticed, then the power
> sweeps back up.
> 
> The merit of this whole idea is that it should both save the node power,
> but when implemented correctly also improve the total throughput of the
> network. This last point because nodes transmit with less power, thus
> causing less interference with nodes further away.
> 
> If there is interest in having this feature merged in mainline RIOT-os,
> I'm willing to work on this to make sure that the code quality is as
> required. The code can be viewed and tracked at
> https://github.com/bergzand/RIOT/tree/mwn2
> 
> Regards,
> Koen
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> 

-- 
Peter Kietzmann

Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel