Subject: Re: [Roll] [ROLL] Energy metric for link

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

Hello Alex and Richard,

An effective energy metric should be completely agnostic of:

1. The PHY/MAC employed by the router (baud rate)
2. The maximum DPDU that is supported by the PHY/MAC (128 bytes in 802.15.4). Therefore expressing energy in terms of the 1280 MTU is meaningless for most wireless technologies, given that they fragment the packet anyway into the max DPDU length packets.
3. Battery chemistry, battery depletion level, recharge cycles, device internal power supply conversion losses etc etc

This should all be an internal device matters that would all be compacted in a single energy metric. A very simple one that makes sense is milliseconds/second because it suits all currently existing RF technologies that we are targeting in ROLL.

Bits/second would be PHY/MAC dependent.

Thks

Date: Wed, 29 Apr 2009 16:18:51 +0200
From: Alexandru Petrescu <[email-masked]>
Subject: Re: [Roll] Energy metric for link
To: Richard Kelsey <[email-masked]>
Cc: [email-masked], [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=UTF-8; format=flowed

Richard Kelsey a ?crit :
> Date: Tue, 28 Apr 2009 15:35:50 +0200 From: Alexandru Petrescu 
> <[email-masked]>
> 
> Richard Kelsey a ?crit :
>> 
>> 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,
> 
> This - relating bandwidth uniquely to battery-level - seems a stretch 
> to me.  Supposedly, the way batteries deplete (the time it takes to 
> send a 1280bytes at a high bandwidth) vary largely with other factors 
> such as battery age and number of recycle duties.
> 
> Battery level need be only one input into the bandwidth calculation.
> Basically, each node would make its own determination as to the 
> bandwidth it could support, taking into account whatever local state 
> that it deemed relevent. That limit could then be both reported to 
> other devices and enforced by the node itself.

Richard, I can understand a node would need more battery to transmit at higher speed (higher bandwidth).

I can also see a node settling for less transmission speed if it had less battery available.

You seem to say nodes would exchange each other's such limits and maybe elect the lowest common denominator for that limit, and all conclude to transmit at that bandwidth limit.

Sounds as an idea which should be listed too.

It's different than the energy metric for the link idea I suggested earlier.

May I then ask: what should be encoded in the metric?  Bandwidth? 
expressed how on bits/secods?  Millseconds?

Alex

> In making routing decisions, what matters in the end is the bandwidth 
> and latency through each possible relay.  I think it would be both 
> simpler and more effective to have each node be responsible for 
> determining its own bandwidth and latency constraints rather than have 
> each node report its internal condition (link and battery parameters, 
> for example) and have some other device translate those into bandwidth 
> and latency constaints.
> 
> -Richard Kelsey
> 

"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]

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: Wed, 29 Apr 2009 23:54:42 +0200

> 1. The PHY/MAC employed by the router (baud rate)

I agree.

> 2. The maximum DPDU that is supported by the PHY/MAC (128 bytes in
> 802.15.4). Therefore expressing energy in terms of the 1280 MTU is
> meaningless for most wireless technologies, given that they fragment
> the packet anyway into the max DPDU length packets.

But this contradicts 1 above, no?  If the link metric is independent of 
PHY/MAC then it doesn't care of DPDU no?

> 3. Battery chemistry, battery depletion level, recharge cycles,
> device internal power supply conversion losses etc etc

I agree.

> This should all be an internal device matters that would all be
> compacted in a single energy metric. A very simple one that makes
> sense is milliseconds/second because it suits all currently existing
> RF technologies that we are targeting in ROLL.

But second is not an unit for energy/power, like Watt/Joule/Amp-hour 
are, no?

I think the unit chosen to represent and encode should be a unit used 
straightforardly during the measurements.   The measurement should be as 
easy as counting bytes.  Some chipsets report energy/power in a certain 
unit.

I could open up another thread about choice of unit of measurement, and 
how we call it "energy metric" or "power metric" - Watt, Joule, 
amp-hour, horsepower, whatnot.

Alex

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 30 Apr 2009 10:29:10 -0400

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

   1. The PHY/MAC employed by the router (baud rate)
   2. The maximum DPDU that is supported by the PHY/MAC (128 bytes in
      802.15.4). Therefore expressing energy in terms of the 1280 MTU is
      meaningless for most wireless technologies, given that they
      fragment the packet anyway into the max DPDU length packets.
   3. Battery chemistry, battery depletion level, recharge cycles, device
      internal power supply conversion losses etc etc

I think we are trying to solve two different problems:

 A) Energy-aware routing that minimizes the total
    energy used.

 B) Energy-aware routing that takes into account the
    energy constraints of individual devices.

Bits/second doesn't work for A, because it doesn't
take into account the energy cost of the PHY/MAC.
Bits/second does work for B, because what matters is
a device's capacity for forwarding messages, which
already factors in the energy cost of the PHY/MAC.

                           -Richard Kelsey