Re: [coman] Merged terminology draft

[Carsten Bormann <[e-mail]>]

Hi Peter,

in RFC6606, we are using the following terms (section 5):

   o  host nodes drawing their power from primary batteries or using
      energy harvesting (sometimes called "power-constrained nodes")

   o  mains-powered host nodes (an example of what we call "power-
      affluent nodes")

   o  power-affluent (but not necessarily mains-powered) high-
      performance gateway(s)

   ... (further distinctions not relevant here)

Clearly, it is a bit more complicated than just power-constrained vs. power-affluent.

Even for power-affluent nodes, we don't want to waste energy (green and all that).
One group of power-affluent nodes has a tens-of-kJ secondary battery that is regularly recharged (e.g., smartphones), so the energy supply is large, but with a defined limit per period (e.g, 24 hours for most smartphones); a typical amount of power continuously available (on average) is in the hundreds of mW.

The typical primary-battery powered node has an average power availability on the order of tens to hundreds of µW.  So there is a clear difference -- around three orders of magnitude.  That should nicely separate the classes.

Energy harvesting nodes are different enough to warrant their own group.  But there is a group of energy harvesting devices that find enough energy to almost be power-affluent.  So it might be useful to actually give an approximate boundary, e.g., in µW actually available averaged over a long time.  (That doesn't work very well for event-based harvesting, but you can just assume an event frequency and likely will arrive at a useful number.)

Grüße, Carsten


On Nov 9, 2012, at 09:51, peter van der Stok <[e-mail]> wrote:

> Dear all,
> 
> Next to the classification on memory, I should like to add a classification on power availability. In small nodes the largest power consumer is the transmitter. So I propose to classify the nodes according to their power-supply expressed as its transmission capacity. I propose three types of devices:
> 
> P0: battery-less devices. They have a capacitor which is charged by harvesting power delivered by a small movement or light. The stored energy  is just sufficient to send 1 or at most 2 packets per communication. For example, think of a light switch where the transmission power is delivered by pushing the button.
> 
> P1: battery-constrained devices. They have a battery with a limited charge. The device can continue sending packets over years by executing a cycle of relatively long off periods and short on periods in which a few packets can be sent and received. For example, think of a battery-powered temperature sensor with a life-time of 7-10 years.
> 
> P2: battery-unconstrained devices. They may have a battery which is usually rechargeable. The device can send and receive packets at any moment during its operational life. For example, think of a thermostat connected to an external power supply.
> 
> Hope this is helpful.
> 
> Peter van der Stok
> 
> 
> Carsten Bormann schreef op 2012-11-08 20:43:
>> As discussed in LWIG and COMAN today, Mehmet and I have extracted our
>> common, "essential" terminology out of the LWIG WG document and
>> Mehmet's COMAN draft, and merged it into one document.
>> 
>> The intention is to move this forward within LWIG independently, in an
>> expedited way, and reference it from the next version of
>> draft-ietf-lwig-guidance as well as further COMAN documents.
>> 
>> Since we got positive feedback in the LWIG meeting for this little
>> piece of surgery, I'm now asking the LWIG chairs to ask the question
>> on the mailing list for working group adoption of this draft.
>> 
>> Htmlized:        http://tools.ietf.org/html/draft-bormann-lwig-terms-00
>> 
>> Clearly, this isn't perfect yet, but further improving the document is
>> the point of the WG process.
>> Of course, comments that could lead to improvement are highly welcome.
>> 
>> Grüße, Carsten
>> 
>> _______________________________________________
>> coman mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/coman
> 
> _______________________________________________
> coman mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/coman