Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of

From: "Robert Assimiti" <[email-masked]>
Date: Mon, 27 Apr 2009 17:03:16 -0400

Hello,

It is my understanding that the final goal of the ROLL group is to have an interoperable routing methodology for LLNs.

The key word here is not just interoperability, but fair interoperability within a multipath battery operated LLN. 

Anyone that has worked with battery powered wireless nodes knows that prolonged battery life (building a wireless router that will actually deliver the advertised battery life) is quite a difficult thing in a multipath wireless environment.

There must be (IMHO) a system of checks and balances that is put into place (hooks in each device) that ensure that routers behave fairly and are good neighbors and routers.

Otherwise, a vendor could always restrict (or minimize) routing of other router's packets and save all battery for its internally generated packets.

Let's break down the operation of a wireless LLN node (don't know enough about PLC technology, therefore I will not include it in the discussion).

The battery depleting operations that a wireless router participates in are:

1. Routing/forwarding of PDU's for other nodes
	a. Running its receiver periodically in order to listing to incoming PDU's that need routing
	b. Sending the PDUs received from other nodes along the appropriate route
2. Sending PDUs internally  generated by the battery
3. Advertisements that allows other nodes to join the network or  beaconing for synchronization etc

Therefore, all these operations need to be captured in a metric, a metric that can be shared with other nodes, or possibly a central management entity.

When joining the network, each node should report its energy capabilities such as:

1. I can run my receiver for X seconds/hour in order to receive incoming PDU's that need routing. 
2. I can spend Y seconds/ hour TXing PDUs on behalf of other nodes (routing) and my internally generated PDUs
3. I can spend Z seconds/ hour advertising for other devices that want to join the network (beacons for synch etc)

Once this parameters are available as READ ONLY MIB attributes, other nodes (or a central management entity in a deterministic network) can request this MIBs and base their routing decision on them.

What do YOU think?

"The nice thing about standards is that there are so many to choose from." - Andrew S. Tanenbaum 
Robert Assimiti
Executive Staff Engineer
Office: [678]-202-6859
Mobile: [404]-578-0205
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, April 27, 2009 3:00 PM
To: [email-masked]
Subject: Roll Digest, Vol 15, Issue 32

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/roll

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send Roll mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/roll
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Roll digest..."

Today's Topics:

   1. Re: Energy metric for link (was: Polling WG for adoption of
      Metrics Draft) (Richard Kelsey)
   2. Re: Energy metric for link (was: Polling WG for adoption of
      Metrics Draft) (Mukul Goyal)

----------------------------------------------------------------------

Message: 1
Date: Mon, 27 Apr 2009 11:04:27 -0400
From: Richard Kelsey <[email-masked]>
Subject: Re: [Roll] Energy metric for link (was: Polling WG for
	adoption of	Metrics Draft)
To: [email-masked]
Cc: [email-masked]
Message-ID: <[email-masked]>

   Date: Fri, 24 Apr 2009 23:31:09 +0200
   From: Michele Rossi <[email-masked]>

   In some cases, we may want to extend the lifetime of some specific
   nodes due to their location in the network or to their specific
   function, and residual energies can be used as a metric to implement
   this.

This requires a mechanism to determine which nodes should
use their residual energy to originate messages and which
nodes should use their residual energy to forward messages.

   Thus, I agree with Mukul in that a node could locally
   decide whether to participate or not in the routing based
   on local metrics, such as its residual battery level
   (among others). As an example, nodes in a sensor network
   that are sensing an important event and that are also
   running out of battery could decide to use their energy
   to send their measurements to a gathering point rather
   than relaying messages from other nodes.

How does a node determine whether its measurements are more
or less important than some other device's measurements?
Not participating in routing makes sense only if the
device's local measurements have a higher priority than
other devices'.  This doesn't seem like a decision that can
be made locally.

If every node decides to reserve the last X% of its battery
for its own measurements, then a network is likely to
shut down as soon as a significant number of nodes is down to
X% battery.  This make sense only if X is zero.  Why shut
down when there is still energy available?

   Finally, I agree with Richard in that using a link metric
   would lead to more stable routing.

That wasn't the point I was trying to make.  My point was
that it makes more sense to treat a battery powered device
as being bandwith limited, with the limit determined by its
initial energy and its design lifetime, than as a device
that has one behavior for the first part of its lifetime and
then switches to some other behavior when its battery gets
low.  How this is reflected in a metric is a separate issue.

For example, a battery-powered node could dynamically adjust
its cost(s) to be as low as possible within its bandwidth
limit.  If it forwards too many messages it pushes the cost
up; too few and it reduces its cost, down to some floor
determined by its non-energy-related costs.  This would
maximize the utility of the network while ensuring that
the device lasts as long as it is meant to.

                                 -Richard Kelsey

------------------------------

Message: 2
Date: Mon, 27 Apr 2009 13:49:34 -0500 (CDT)
From: Mukul Goyal <[email-masked]>
Subject: Re: [Roll] Energy metric for link (was: Polling WG for
	adoption of Metrics Draft)
To: Richard Kelsey <[email-masked]>
Cc: [email-masked], [email-masked]
Message-ID:
	<[email-masked]>
	
Content-Type: text/plain; charset=utf-8

I am not sure if the routing protocol MUST aim for maximization of the network life time. There will be a variety of the nodes in the network - some nodes dedicated to forwarding packets of others, some nodes just acting as end points and some nodes doing both operations. I think, rather than aiming for optimizing the life time/performance, the routing protocol should allow different "local" policies to be enforced. The routing protocol should not decide whether a node must participate in routing. The routing protocol should find the best routes among the nodes willing to forward packets. A node should be able to decide whether to forward packets or not based on the local policy factors such as battery levels.

Thanks
Mukul
   
----- Original Message -----
From: "Richard Kelsey" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Sent: Monday, April 27, 2009 10:04:27 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of  Metrics Draft)

   Date: Fri, 24 Apr 2009 23:31:09 +0200
   From: Michele Rossi <[email-masked]>

   In some cases, we may want to extend the lifetime of some specific
   nodes due to their location in the network or to their specific
   function, and residual energies can be used as a metric to implement
   this.

This requires a mechanism to determine which nodes should
use their residual energy to originate messages and which
nodes should use their residual energy to forward messages.

   Thus, I agree with Mukul in that a node could locally
   decide whether to participate or not in the routing based
   on local metrics, such as its residual battery level
   (among others). As an example, nodes in a sensor network
   that are sensing an important event and that are also
   running out of battery could decide to use their energy
   to send their measurements to a gathering point rather
   than relaying messages from other nodes.

How does a node determine whether its measurements are more
or less important than some other device's measurements?
Not participating in routing makes sense only if the
device's local measurements have a higher priority than
other devices'.  This doesn't seem like a decision that can
be made locally.

If every node decides to reserve the last X% of its battery
for its own measurements, then a network is likely to
shut down as soon as a significant number of nodes is down to
X% battery.  This make sense only if X is zero.  Why shut
down when there is still energy available?

   Finally, I agree with Richard in that using a link metric
   would lead to more stable routing.

That wasn't the point I was trying to make.  My point was
that it makes more sense to treat a battery powered device
as being bandwith limited, with the limit determined by its
initial energy and its design lifetime, than as a device
that has one behavior for the first part of its lifetime and
then switches to some other behavior when its battery gets
low.  How this is reflected in a metric is a separate issue.

For example, a battery-powered node could dynamically adjust
its cost(s) to be as low as possible within its bandwidth
limit.  If it forwards too many messages it pushes the cost
up; too few and it reduces its cost, down to some floor
determined by its non-energy-related costs.  This would
maximize the utility of the network while ensuring that
the device lasts as long as it is meant to.

                                 -Richard Kelsey

------------------------------

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

End of Roll Digest, Vol 15, Issue 32
************************************

This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 Apr 2009 14:10:47 +0200

Hi Robert,

With respect your text below, I think the following:

Robert Assimiti a écrit :
[...]
> 2. I can spend Y seconds/ hour TXing PDUs on behalf of other nodes 
> (routing) and my internally generated PDUs
> 
> 3. I can spend Z seconds/ hour advertising for other devices that 
> want to join the network (beacons for synch etc)

I believe a ROLL router should send on each of its interface an RA (ICMP
Router Advertisement) containing a description of the energy needed to
send or receive an 1280byte-sized packet on that link:

1. Sending an MTU packet on this link requires max X watts
2. Sending an MTU packet on this link requires min Y watts
3. Receiving an MTU packet on this link requires max X watts
4. Receiving an MTU packet on this link requires min Y watts

This information may be used by the receivers in many different ways:
e.g. a host chooses among two default routers the one through which
lower energy is needed (a default router qualifier is also in RA), e.g.
two neighboring routers learn from each other's RA that link's
characteristics, and many more.

This same way of encoding the energy for link in a metric can be encoded
in OSPF and RIP metrics (and not in RA).  In this way the OSPF or RIP
routing protocol could build paths depending not only on hop count but
also on the energy needed to travel that path.

What do people think about this energy metric for a link?

> Once this parameters are available as READ ONLY MIB attributes, other
>  nodes (or a central management entity in a deterministic network) 
> can request this MIBs and base their routing decision on them.

These paramters, or metrics, should certainly figure in a ROLL MIB
(Management Information Base), I agree.

Alex

---

From: "Robert Assimiti" <[email-masked]>
Date: Wed, 29 Apr 2009 16:24:56 -0400

Hello Alex,

I completely agree with the necessity of a "energy cost" metric in routing decisions.

I would like to add though that this has to be translated to a bandwidth capacity metric as well (speaking from router A's point of view):

1. If you want me to route an MTU for you it will cost me (battery operated router A) xxx mW
2. I have the capacity (since I am battery operated) to route yyy MTU's/per hour.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Tuesday, April 28, 2009 8:11 AM
To: Robert Assimiti
Cc: [email-masked]
Subject: Re: [Roll] Energy metric for link

Hi Robert,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Apr 2009 23:48:04 +0200

> 2. I have the capacity (since I am battery operated) to route yyy MTU's/per hour.

I tend to agree, and would qualify it as a node metric.  I think this 
metric tends to be hard to express, many semantics possible... needs 
many perspectives to be looked from...

Alex