Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed

From: Kris Pister <[email-masked]>
Date: Mon, 03 Nov 2008 21:28:23 -0800

JP - I'd like to understand more about your flags. 
If I have a network in which I expect that all motes last for 7 years, 
where do I set the "I'm low on energy" flag?  At 50% (ideally 3.5 
years)?  At 5% (ideally 3 months)?
In the first case, for roughly half of my network lifetime, all of my 
network will have set the "I'm low on energy" flag, and I will have no 
useful information with which to make routing decisions.
In the second case, I have almost no useful information until it's too 
late - one year into operation and several of the busiest motes are 
almost dead, while a mote with a much bigger battery still has almost 
all of it's charge.  So in this case the information shows up too late 
to be useful.
I'm sure that's not the way you see it.  What am I missing?

ksjp

JP Vasseur wrote:
> Hi Miguel,
>
>
> On 10/31/08 12:24 PM, "Miguel Sanchez" <[email-masked]> wrote:
>
>   
>> Hi JP,
>>
>>
>>
>> On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur <[email-masked]> wrote:
>>     
>>> Hi Kris,
>>>
>>>
>>> On 10/30/08 5:33 PM, "Kris Pister" <[email-masked]> wrote:
>>>
>>> I agree with Miguel that we need a standard way of energy reporting, and I
>>> agree with JP that it's hard to do.
>>> Part of the challenge is that energy sources and storage vary so much. We
>>> have:
>>>  * line power - great if you can get it!
>>>  * battery storage
>>>       - this is time varying.  The available energy in a battery is a strong
>>> function of the temperature and the usage profile.  So a battery powered
>>> mote may correctly calculate five years of lifetime in summer, and then that
>>> winter under the exact same load conditions it may correctly calculate a
>>> lifetime of ten years.  The same mote with the same battery may have better
>>> performance in summer at higher loads.
>>>
>>> JP> and usage profile may also change.
>>>
>>>  * capacitive storage
>>>  * energy scavenging
>>>       - this is time varying, and tough to bound (usefully
>>>
>>> JP> this is why I'm questioning the usefulness of knowing the remaining
>>> energy expressed in Joules or other metrics. Knowing this value will not
>>> tell you anything as to whether you should or should not use that node when
>>> computing the path. Another metric may be the remaining estimated lifetime
>>>       
>> I disagree.
>>
>> At least if remaining energy is infinitum (mains powered) tells you something.
>>
>> OTOH, if limited, depending on other properties of the nodes (like
>> where it gets its energy from) it is also useful for making routing
>> decisions too.
>>     
>
> OK let's try to step back. I'm proposing a flag-based mechanism to avoid the
> use of a node should this node run out of energy. The decision to set the
> flag is made by the node (no specified) according to many parameters
> (estimated like time, ... Etc). Some nodes having more power may make use of
> complex models.
>
> If you advertise your remaining power in Joules, how would you expect the
> nodes to change their routing decisions since they have no idea of whether
> you are running low in energy (it highly depends on what the node does, the
> external conditions, ... Etc) ?
>
> Thanks.
>
> JP.
>
>   
>>> but still, is the node capable (without consuming too much energy) of
>>> gathering historical data etc ... to provide an accurate value hoping that
>>> other criterion such as usage profile or temperature as you pointed out will
>>> not change ?
>>>
>>> All of this makes energy/power/lifetime reporting painful, yet I can not
>>> picture a successful routing protocol that doesn't somehow take these
>>> factors into account.
>>>
>>>       
>> Kind regards,
>>
>> Miguel
>>     
>
>   
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Tue, 04 Nov 2008 19:16:29 +0100

Hi Kris,

> I'm sure that's not the way you see it.  What am I missing?

See it as a trade-off between frequent accurate updates (=> requiring
energy, risk of routing oscillations, ...) and no information at all. If you
make the assumption of uniform energy consumption, then flags are always
useless (so does more up to date data). On the other hand if you see the use
of such flags as safeguard mechanisms, this could be useful to start
rerouting the traffic around nodes running out of battery. Suppose that the
traffic is not equally balanced in the network, you may end up with nodes
consuming battery at a much higher rates than others, in which case the
flags may be useful, with no risk of oscillation.

Thoughts ?

Cheers,

JP.

---

From: Kris Pister <[email-masked]>
Date: Tue, 04 Nov 2008 16:05:44 -0800

Well, we both agree that there will be load imbalance and differential 
rate of energy consumption,
and we both agree that oscillations will be bad.  I think that we may 
have a different picture of the
frequency of those oscillations, though.  I think that most/all of the 
systems described in the
requirements docs have battery lifetime requirements measured in years.  
This implies a minimum
update rate of, oh, something like monthly.  Sending a few tens of bytes 
of data describing
energy and power state on a daily basis is both far more frequent than 
we need, and unlikely
to cause *wasteful* oscillations.  If there is some route bouncing with 
a one day or week period, maybe
that's actually optimal.  It's certainly not expensive.

I'm still very curious as to where you think that we should set the "low 
energy" flag level.  Based on the two scenarios that I presented, I 
don't see that single-bit flags have much value.  As you pointed out in 
your response, the traffic will not be balanced.  Either I set the flag 
near midpoint, and it doesn't help much, or I set well below midpoint, 
and it doesn't help very much.

I can imagine scenarios in which it works great.  Unfortunately, working 
well 50% of the time doesn't do us much good.  We don't have to handle 
every situation, but we have to at least deal with common problems that 
come up in real networks.

ksjp

---

From: JP Vasseur <[email-masked]>
Date: Wed, 05 Nov 2008 09:57:46 +0100

Hi Kris,

On 11/5/08 1:05 AM, "Kris Pister" <[email-masked]> wrote:

> Well, we both agree that there will be load imbalance and differential rate of
> energy consumption,
> and we both agree that oscillations will be bad.
> 
> JP> Indeed.
> 
> I think that we may have a different picture of the
> frequency of those oscillations, though.  I think that most/all of the systems
> described in the
> requirements docs have battery lifetime requirements measured in years.  This
> implies a minimum
> update rate of, oh, something like monthly.  Sending a few tens of bytes of
> data describing
> energy and power state on a daily basis is both far more frequent than we
> need, and unlikely
> to cause *wasteful* oscillations.
> 
> JP> Also agreeing.
> 
> If there is some route bouncing with a one day or week period, maybe
> energy" flag level.  Based on the two scenarios that I presented, I don't see
> that single-bit flags have much value.  As you pointed out in your response,
> the traffic will not be balanced.  Either I set the flag near midpoint, and it
> doesn't help much, or I set well below midpoint, and it doesn't help very
> much.
> 
> I can imagine scenarios in which it works great.
> 
> JP> So do I.
> 
> Unfortunately, working well 50% of the time doesn't do us much good.  We don't
> have to handle every situation, but we have to at least deal with common
> problems that come up in real networks.
> 
> JP>  I was actually referring to 2 levels of flagging providing enough
> flexibility ... But we can think of using a more accurate model with higher
> granularity. I personally think that the number of metrics specified in WHART
> is too high, may be a 2-flag mechanism may be too coarse. Then we will have to
> also specify how often to set these metrics since this is not in this case an
> implementation issue. We will also have to specify how to compute those
> metrics.
> 
> Can we try to find a middle ground solution ?
> 
> Cheers.
> 
> JP.
> 
> ksjp
> 
> JP Vasseur wrote:
>>  
>> Hi Kris,
>> 
>> 
>> On 11/4/08 6:28 AM, "Kris Pister" <[email-masked]>
>> <mailto:[email-masked]>  wrote:
>> 
>>   
>>  
>>>  
>>>> On 10/31/08 12:24 PM, "Miguel Sanchez" <[email-masked]>
>>>> <mailto:[email-masked]>  wrote:
>>>> 
>>>>   
>>>>       
>>>>  
>>>>>  
>>>>> Hi JP,
>>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur <[email-masked]>
>>>>> <mailto:[email-masked]>  wrote:
>>>>>     
>>>>>         
>>>>>  
>>>>>>  
>>>>>> Hi Kris,
>>>>>> 
>>>>>> 
>>>>>> On 10/30/08 5:33 PM, "Kris Pister" <[email-masked]>
>>>>>> <mailto:[email-masked]>  wrote:
>>>>>>

---

From: [email-masked]
Date: Wed, 5 Nov 2008 16:59:02 -0600

Why is the IETF trying to establish when the energy flag needs to be set 
for low battery?  This is an application issue. 

Remaining energy is not a function of time, it's a function of remaining 
energy.  In our current wireless products, we have a comparator that will 
shut the sensor down at a given voltage level.  We have actually 
calculated the number of joules required per transaction and have back 
calculated the voltage level at which point we will issue a low-battery 
alarm.  We set the voltage level to alarm about 3 months before the device 
shuts down, giving the customer 3 months to change the battery.  This is 
for a device that transmits once a minute for about 3 msecs.  The battery 
status is included (1-bit). with every transaction.  Two alkaline  'c' 
cells will last about 10 years, but due to shelf life, we specify 5 year 
battery life.

>From my viewpoint all battery powered wireless devices need to transmit 
their battery status.  For interoperability purposes, this should be 
dictated.  However, this is not a protocol issue, much less a routing 
issue.  This should be something done by the implementers or specified at 
the alliance level (e.g. IPSO).

Jerry

Kris Pister <[email-masked]> 
Sent by: [email-masked]
11/04/2008 06:06 PM

To
JP Vasseur <[email-masked]>
cc
ROLL WG <[email-masked]>
Subject
Re: [Roll] ROLL Routing Metrics - WF feed-back needed

Well, we both agree that there will be load imbalance and differential 
rate of energy consumption,
and we both agree that oscillations will be bad.  I think that we may have 
a different picture of the
frequency of those oscillations, though.  I think that most/all of the 
systems described in the
requirements docs have battery lifetime requirements measured in years. 
This implies a minimum
update rate of, oh, something like monthly.  Sending a few tens of bytes 
of data describing
energy and power state on a daily basis is both far more frequent than we 
need, and unlikely
to cause *wasteful* oscillations.  If there is some route bouncing with a 
one day or week period, maybe
that's actually optimal.  It's certainly not expensive.

I'm still very curious as to where you think that we should set the "low 
energy" flag level.  Based on the two scenarios that I presented, I don't 
see that single-bit flags have much value.  As you pointed out in your 
response, the traffic will not be balanced.  Either I set the flag near 
midpoint, and it doesn't help much, or I set well below midpoint, and it 
doesn't help very much.

ksjp

JP Vasseur wrote: 
Hi Kris,

See it as a trade-off between frequent accurate updates (=> requiring
energy, risk of routing oscillations, ...) and no information at all. If 
you
make the assumption of uniform energy consumption, then flags are always
useless (so does more up to date data). On the other hand if you see the 
use
of such flags as safeguard mechanisms, this could be useful to start
rerouting the traffic around nodes running out of battery. Suppose that 
the
traffic is not equally balanced in the network, you may end up with nodes
consuming battery at a much higher rates than others, in which case the
flags may be useful, with no risk of oscillation.

Thoughts ?

Cheers,

JP. 

ksjp

JP Vasseur wrote:
 
Hi Miguel,

 
Hi JP,

Hi Kris,

I agree with Miguel that we need a standard way of energy reporting, and I
agree with JP that it's hard to do.
Part of the challenge is that energy sources and storage vary so much. We
have:
 * line power - great if you can get it!
 * battery storage
      - this is time varying.  The available energy in a battery is a
strong
function of the temperature and the usage profile.  So a battery powered
mote may correctly calculate five years of lifetime in summer, and then
that
winter under the exact same load conditions it may correctly calculate a
lifetime of ten years.  The same mote with the same battery may have 
better
performance in summer at higher loads.

 * capacitive storage
 * energy scavenging

JP> this is why I'm questioning the usefulness of knowing the remaining
energy expressed in Joules or other metrics. Knowing this value will not
tell you anything as to whether you should or should not use that node 
when
computing the path. Another metric may be the remaining estimated lifetime

I disagree.

At least if remaining energy is infinitum (mains powered) tells you
something.

OK let's try to step back. I'm proposing a flag-based mechanism to avoid 
the
use of a node should this node run out of energy. The decision to set the
flag is made by the node (no specified) according to many parameters
(estimated like time, ... Etc). Some nodes having more power may make use 
of
complex models.

If you advertise your remaining power in Joules, how would you expect the
nodes to change their routing decisions since they have no idea of whether
you are running low in energy (it highly depends on what the node does, 
the
external conditions, ... Etc) ?

Thanks.

JP.

but still, is the node capable (without consuming too much energy) of
gathering historical data etc ... to provide an accurate value hoping that
other criterion such as usage profile or temperature as you pointed out
will
not change ?

 
Kind regards,

Miguel

---

From: Kris Pister <[email-masked]>
Date: Wed, 05 Nov 2008 20:11:57 -0800

Jerry - I'm not trying to get the IETF decide the threshold for any 
flags.  My point is that a single bit flag is virtually useless for 
making intelligent routing decisions, regardless of what threshold value 
you choose for it.

You say that remaining energy is not a function of time, and yet the 
units you use to describe where you set the threshold are "months" :)  
Somehow we have to make the same kind of translations between Joules and 
months, and for networks where the routers are battery powered, this IS 
a routing issue.

Here's why: ignoring energy in routing decisions, protocol X creates 
networks that have a distribution of lifetimes varying, for example, 
from three to fifteen years.  Protocol Y, using energy in its routing 
decisions, builds networks that have the same mean lifetime, but a 
distribution that is much tighter - from 9 to 12 years.  Which one would 
you rather buy?  One where you start replacing batteries after 3 years, 
or one were you replace them all at 9 years?

ksjp

[email-masked] wrote:
>
> Why is the IETF trying to establish when the energy flag needs to be 
> set for low battery?  This is an application issue.  
>
> Remaining energy is not a function of time, it's a function of 
> remaining energy.  In our current wireless products, we have a 
> comparator that will shut the sensor down at a given voltage level. 
>  We have actually calculated the number of joules required per 
> transaction and have back calculated the voltage level at which point 
> we will issue a low-battery alarm.  We set the voltage level to alarm 
> about 3 months before the device shuts down, giving the customer 3 
> months to change the battery.  This is for a device that transmits 
> once a minute for about 3 msecs.  The battery status is included 
> (1-bit). with every transaction.  Two alkaline  'c' cells will last 
> about 10 years, but due to shelf life, we specify 5 year battery life.
>
> From my viewpoint all battery powered wireless devices need to 
> transmit their battery status.  For interoperability purposes, this 
> should be dictated.  However, this is not a protocol issue, much less 
> a routing issue.  This should be something done by the implementers or 
> specified at the alliance level (e.g. IPSO).
>
> Jerry
>
>
>
>
>
> *Kris Pister <[email-masked]>*
> requirements docs have battery lifetime requirements measured in 
> years.  This implies a minimum
> update rate of, oh, something like monthly.  Sending a few tens of 
> bytes of data describing
> to cause *wasteful* oscillations.  If there is some route bouncing 
> with a one day or week period, maybe
> I'm still very curious as to where you think that we should set the 
> "low energy" flag level.  Based on the two scenarios that I presented, 
> I don't see that single-bit flags have much value.  As you pointed out 
> in your response, the traffic will not be balanced.  Either I set the 
> flag near midpoint, and it doesn't help much, or I set well below 
> midpoint, and it doesn't help very much.
>
> I can imagine scenarios in which it works great.  Unfortunately, 
> working well 50% of the time doesn't do us much good.  We don't have 
> to handle every situation, but we have to at least deal with common 
> On 11/4/08 6:28 AM, "Kris Pister" _<[email-masked]>_ 
> On 10/31/08 12:24 PM, "Miguel Sanchez" _<[email-masked]>_ 
> On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur _<[email-masked]>_ 
> On 10/30/08 5:33 PM, "Kris Pister" _<[email-masked]>_

---

From: [email-masked]
Date: Thu, 6 Nov 2008 14:04:12 -0600

Kris,

I'm getting your point, to a point...

First off, in the Commercial Building market, all routering devices will 
be lines powered and hence the routing protocol need not concern itself 
with power starved routers.  You must be vying for some sort of 
synchronous network where the routers power up on a very short duty cycle. 
 Our radios typically require 10000x more energy (~27ma) when powered up 
and transmitting or receiving  than asleep (2uA).  You would blow out the 
joules of any reasonably sized battery quite quickly if the receiver 
needed to be on for extended periods on the off-chance that a message 
needed to be routered through it. 

As for the routing protocol needing a priori knowledge of the battery 
status of a device to determine selected paths, I still don't see this as 
a network routing parameter.  The node that becomes energy starved simply 
needs to stop forwarding routed messages.   The transport will quickly 
notice that messages are not reaching their destination and advertise for 
a new path to which our energy starved device won't respond.  A more 
graceful approach would be for the energy starved node to simply tell the 
source node that it is temporarily out of the routering business.  This 
functionality needs to be in place anyway since even in normal operation, 
an existing path might get blocked.

By advertising remaining energy throughout the network and making systemic 
routing choices based on available energy seems like a nice thing to do 
and would tend to balance the total available energy across the mesh. 
However, the network also must understand the application running on the 
node to make the choice.  For example, let's say I have a battery powered 
repeater installed in a sparse portion of the mesh.  This device has no 
other meaning in life but to route messages.  Rerouting around this device 
saves the energy on a device that has no reason to save energy.  Also, 
remember this repeater was strategically placed to 'fill-in' the mesh.  By 
taking it out of the mesh routes, all the other nodes will need to use up 
more of their available energy to make up for this missing node.

Conversely, (kind of!!!) let's say I have a sensor that needs to report 
status temporally.  Even if I stop routing, I still need to awaken to do 
my own task on a periodic basis.  In many cases I can synchronize my 
application with the duty cycle of the network.  Now I can continue to 
perform both jobs without reducing energy any more than I would performing 
my one required job.

My point being that it is important to understand the application 
requirements as well as battery status to make judicious routing 
decisions.  Why not let each device decide no its own if it can save power 
by taking itself out of the routing paths.  The mesh would then just 
re-form as needed around the devices.

Jerry

11/05/2008 10:08 PM

To
[email-masked]
cc
ROLL WG <[email-masked]>
Subject
Re: [Roll] ROLL Routing Metrics - WF feed-back needed

ksjp

---

From: "Anders Brandt" <[email-masked]>
Date: Mon, 10 Nov 2008 16:55:29 +0100

Jerry touches a point I forgot to mention in relation to Kris' previous
postings.

I fully support the idea of preferred routers running on battery.
We definitely also see this application in the home control domain.
 
> ...let's say I have a battery powered repeater installed in a sparse
portion of the mesh.  This device has no other meaning in
> life but to route messages. Rerouting around this device saves the
energy on a device that has no reason to save energy.
>  Also, remember this repeater was strategically placed to 'fill-in'
the mesh.
 
In order to attract interest from the routing protocol, such a node
should be able to signal "mains powered" or even better:
"I have plenty of battery".
Obviously, it should lower that indication to normal "battery-powered"
if running close to low; ending with "battery low".

br. Anders

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 6. november 2008 21:04
To: Kris Pister
Cc: ROLL WG; [email-masked]
Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed

Kris, 

First off, in the Commercial Building market, all routering devices will
be lines powered and hence the routing protocol need not concern itself
with power starved routers.  You must be vying for some sort of
synchronous network where the routers power up on a very short duty
cycle.  Our radios typically require 10000x more energy (~27ma) when
powered up and transmitting or receiving  than asleep (2uA).  You would
blow out the joules of any reasonably sized battery quite quickly if the
receiver needed to be on for extended periods on the off-chance that a
message needed to be routered through it.   

As for the routing protocol needing a priori knowledge of the battery
status of a device to determine selected paths, I still don't see this
as a network routing parameter.  The node that becomes energy starved
simply needs to stop forwarding routed messages.   The transport will
quickly notice that messages are not reaching their destination and
advertise for a new path to which our energy starved device won't
respond.  A more graceful approach would be for the energy starved node
to simply tell the source node that it is temporarily out of the
routering business.  This functionality needs to be in place anyway
since even in normal operation, an existing path might get blocked. 

By advertising remaining energy throughout the network and making
systemic routing choices based on available energy seems like a nice
thing to do and would tend to balance the total available energy across
the mesh.  However, the network also must understand the application
running on the node to make the choice.  For example, let's say I have a
battery powered repeater installed in a sparse portion of the mesh.
This device has no other meaning in life but to route messages.
Rerouting around this device saves the energy on a device that has no
reason to save energy.  Also, remember this repeater was strategically
placed to 'fill-in' the mesh.  By taking it out of the mesh routes, all
the other nodes will need to use up more of their available energy to
make up for this missing node. 

Conversely, (kind of!!!) let's say I have a sensor that needs to report
status temporally.  Even if I stop routing, I still need to awaken to do
my own task on a periodic basis.  In many cases I can synchronize my
application with the duty cycle of the network.  Now I can continue to
perform both jobs without reducing energy any more than I would
performing my one required job. 

My point being that it is important to understand the application
requirements as well as battery status to make judicious routing
decisions.  Why not let each device decide no its own if it can save
power by taking itself out of the routing paths.  The mesh would then
just re-form as needed around the devices. 

Jerry 

11/05/2008 10:08 PM 

To

you choose for it.

ksjp

---

From: JP Vasseur <[email-masked]>
Date: Mon, 10 Nov 2008 17:42:39 +0100

Thanks for the feed-back, it is an identified metric (node attribute).

Cheers,

JP. 

On 11/10/08 4:55 PM, "Anders Brandt" <[email-masked]> wrote:

>> > life but to route messages. Rerouting around this device saves the energy
>> on a device that has no reason to save energy.
>> >  Also, remember this repeater was strategically placed to 'fill-in' the
>> mesh.
>  
> In order to attract interest from the routing protocol, such a node should be
> able to signal "mains powered" or even better:
> Obviously, it should lower that indication to normal "battery-powered" if
> running close to low; ending with "battery low".
> br. Anders
> 
>  
> 
> First off, in the Commercial Building market, all routering devices will be
> lines powered and hence the routing protocol need not concern itself with
> power starved routers.  You must be vying for some sort of synchronous network
> where the routers power up on a very short duty cycle.  Our radios typically
> require 10000x more energy (~27ma) when powered up and transmitting or
> receiving  than asleep (2uA).  You would blow out the joules of any reasonably
> sized battery quite quickly if the receiver needed to be on for extended
> periods on the off-chance that a message needed to be routered through it.
> 
> As for the routing protocol needing a priori knowledge of the battery status
> of a device to determine selected paths, I still don't see this as a network
> routing parameter.  The node that becomes energy starved simply needs to stop
> forwarding routed messages.   The transport will quickly notice that messages
> are not reaching their destination and advertise for a new path to which our
> energy starved device won't respond.  A more graceful approach would be for
> the energy starved node to simply tell the source node that it is temporarily
> out of the routering business.  This functionality needs to be in place anyway
> routing choices based on available energy seems like a nice thing to do and
> would tend to balance the total available energy across the mesh.  However,
> the network also must understand the application running on the node to make
> the choice.  For example, let's say I have a battery powered repeater
> installed in a sparse portion of the mesh.  This device has no other meaning
> in life but to route messages.  Rerouting around this device saves the energy
> on a device that has no reason to save energy.  Also, remember this repeater
> was strategically placed to 'fill-in' the mesh.  By taking it out of the mesh
> routes, all the other nodes will need to use up more of their available energy
> to make up for this missing node.
> 
> Conversely, (kind of!!!) let's say I have a sensor that needs to report status
> temporally.  Even if I stop routing, I still need to awaken to do my own task
> on a periodic basis.  In many cases I can synchronize my application with the
> duty cycle of the network.  Now I can continue to perform both jobs without
> reducing energy any more than I would performing my one required job.
> 
> My point being that it is important to understand the application requirements
> as well as battery status to make judicious routing decisions.  Why not let
> each device decide no its own if it can save power by taking itself out of the
> routing paths.  The mesh would then just re-form as needed around the devices.
> 
> Jerry 
> 
> 
> 
> 
>   
>  Kris Pister  <[email-masked]>  11/05/2008 10:08 PM
>   To

---

From: Philip Levis <[email-masked]>
Date: Mon, 10 Nov 2008 13:27:58 -0800

On Nov 10, 2008, at 7:55 AM, Anders Brandt wrote:

> Jerry touches a point I forgot to mention in relation to Kris'  
> previous postings.
>
> > ...let's say I have a battery powered repeater installed in a  
> sparse portion of the mesh.  This device has no other meaning in
> >  Also, remember this repeater was strategically placed to 'fill- 
> in' the mesh.
>
> Obviously, it should lower that indication to normal "battery- 
> powered" if running close to low; ending with "battery low".
> br. Anders
>
>
>

I'm confused by this line of logic. Whether a node advertises itself  
as having lots of energy is less important than the available energy  
along a route. I.e., if the next hop, node A, has lots of energy but  
its next hop, node B, is very limited, the fact that A has lots of  
energy is not particularly useful.

So far, this discussion has assumed that a node must communicate a lot  
of factors to other nodes, so they can apply their own algorithms to  
decide which next hop to take. The issue here is that it assumes the  
optimization criteria are the same; even though the router-to-be wants  
to save energy, the sender wants to optimize latency and so ignores  
energy constraints. Another approach is that each node applies its own  
algorithm to determine its willingness/cost, which other nodes then  
take into account. That is, nodes advertise how good a router they  
think they are, and senders take this into consideration. Otherwise,  
especially in a distributed and dynamic system, senders can be making  
decisions based on out-of-date information which is hard to detect  
inconsistencies on without expensive periodic state exchanges.

E.g., one simple way to articulate energy, rather than "I have X" is  
"How expensive I consider sending a packet." This takes into  
consideration a lot more useful information, and is much more flexible  
to compute and consider.

Phil

---

From: Kris Pister <[email-masked]>
Date: Mon, 10 Nov 2008 14:52:21 -0800

Phil - I agree that the optimal routes are going to be a function of the 
state of all of the nodes along each route, not just one node 
advertising that it's fat and happy.

I don't think that I agree that we're assuming that a node must 
communicate a lot of factors to other nodes.  I can imagine something 
like AODV, but where each node adds its own hop cost.  Depending on 
shared network parameters, each node might add e.g. 1/(remaining 
lifetime) to the total route cost, or it might add it's link-latency to 
the route cost.  I'm not advocating something AODV-like, just pointing 
out that we don't necessarily need to be propagating a lot of state 
information around the network, and potentially complicated (and 
platform dependent) local computations can still be done without the 
global algorithm needing to know the details.

ksjp

Philip Levis wrote:
>> Obviously, it should lower that indication to normal 
>> "battery-powered" if running close to low; ending with "battery low".
>> br. Anders
>>
>>
>>
>

---

From: Kris Pister <[email-masked]>
Date: Mon, 10 Nov 2008 15:30:46 -0800

Jerry - powered routing infrastructure is great if you can afford it.  
For applications which can't, then battery powered routers are a must.  
Whether these use the venerable Low Power Listen approach, or the 
upstart Time Synchronized Mesh approach, you get sub-second latency and 
power consumption that is in the tens of uA.  You're right that I'm 
representing the interests of the synchronous network community - that's 
what industrial automation is using today, with Wireless HART (shipping) 
and ISA100.11a (in draft).
If you only use powered routers, then I agree that the whole 
energy-reporting thing is of little interest.
The requirement for industrial is that we be able to do power-aware and 
latency-sensitive routing though.

ksjp

[email-masked] wrote:
> First off, in the Commercial Building market, all routering devices 
> will be lines powered and hence the routing protocol need not concern 
> itself with power starved routers.  You must be vying for some sort of 
> powered up and transmitting or receiving  than asleep (2uA).  You 
> would blow out the joules of any reasonably sized battery quite 
> quickly if the receiver needed to be on for extended periods on the 
> off-chance that a message needed to be routered through it.  
>
> respond.  A more graceful approach would be for the energy starved 
> node to simply tell the source node that it is temporarily out of the 
> thing to do and would tend to balance the total available energy 
> across the mesh.  However, the network also must understand the 
> application running on the node to make the choice.  For example, 
> let's say I have a battery powered repeater installed in a sparse 
> portion of the mesh.  This device has no other meaning in life but to 
> route messages.  Rerouting around this device saves the energy on a 
> device that has no reason to save energy.  Also, remember this 
> repeater was strategically placed to 'fill-in' the mesh.  By taking it 
> out of the mesh routes, all the other nodes will need to use up more 
> of their available energy to make up for this missing node.
>
> Conversely, (kind of!!!) let's say I have a sensor that needs to 
> report status temporally.  Even if I stop routing, I still need to 
> awaken to do my own task on a periodic basis.  In many cases I can 
> synchronize my application with the duty cycle of the network.  Now I 
> can continue to perform both jobs without reducing energy any more 
> than I would performing my one required job.
>

---

From: Kris Pister <[email-masked]>
Date: Mon, 10 Nov 2008 15:56:45 -0800

I'm confident that we can find a relatively short list of metrics that 
can easily be calculated.
The list from HART is actually not all metrics.  I was using it to 
illustrate that the energy problem is complex.  On the plus side, we 
have an existence proof that it's possible to find a stable working 
solution.  I'm happy if we can do as well or better with fewer metrics 
and slower reporting (15 minutes in hart).

Like the Buddha, we look for the middle way,
ksjp

JP Vasseur wrote:
>
>     JP>  I was actually referring to 2 levels of flagging providing
>     enough flexibility ... But we can think of using a more accurate
>     model with higher granularity. I personally think that the number
>     of metrics specified in WHART is too high, may be a 2-flag
>     mechanism may be too coarse. Then we will have to also specify how
>     often to set these metrics since this is not in this case an
>     implementation issue. We will also have to specify how to compute
>     those metrics.
>
>                 On 10/31/08 12:24 PM, "Miguel Sanchez"
>                 <[email-masked]> <mailto:[email-masked]>  wrote:
>
>                   
>                       
>                  
>
>
>                     Hi JP,
>
>
>
>                     On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur
>                     <[email-masked]> <mailto:[email-masked]>
>                      wrote:
>                         
>                             
>                      
>
>
>                         Hi Kris,
>
>
>     ------------------------------------------------------------------------

---

From: JP Vasseur <[email-masked]>
Date: Thu, 13 Nov 2008 11:38:24 +0100

Hi,

> advertising that it's fat and happy.

Right. Bear in mind that we are discussing node metric. Path characteristics
are locally derived by the computing node !

> global algorithm needing to know the details.

Absolutely.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 13 Nov 2008 11:53:02 +0100

Hi 

See in line,

> latency-sensitive routing though.

Right. The routing MUST thus support this metric, which does not mean that
in a specific scenario like building automation, each node would have to use
that metrics of course.

More below,

>> since even in normal operation, an existing path might get blocked.

Yes but by anticipating this low energy state, you can better balance the
traffic and thus increase the network life duration.

>> across the mesh.

Yes.

However, the network also must understand the
>> of their available energy to make up for this missing node.

Well in that case you may want to have another attribute (preference) and
use it in combination with the energy using hierarchical rules when you
compute the path. 

>> than I would performing my one required job.

Right but you would avoid to drain energy from your battery to route others'
packets.

>> just re-form as needed around the devices.

The decision on how to use the flag is local to the node.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 13 Nov 2008 12:02:07 +0100

Jerry,

It *is* a routing issue since you want to change your routing decision
according to the remaining energy on "each" node.

Thanks.

JP.