Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

[Philip Levis <[e-mail]>]

On Aug 2, 2014, at 12:23 PM, Michael Richardson <[e-mail]> wrote:

> 
> Philip Levis <[e-mail]> wrote:
>> The paper is very helpful, thanks! Can you comment on what is a typical
>> idle slot configuration in a TiSCH network? Can you provide some
>> insight on what fraction of energy is spent in data communication
>> versus control and idle listening?
> 
> Here is a recent post with some real numbers:
>  https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY
> it concerns diet-ESP, but the numbers are correct.

Michael,

I'm confused on what this email message is supposed to be providing: the energy cost of sending a bit? That's pretty simple to calculate. The tradeoff between CPU and network is also very well known, going back to Pottie's "Every bit transmitted brings a sensor node one moment closer to death." If you look at the behavior of most micro controller based devices, the MCU is insignificant -- and 95% of its energy is spent handling interrupts (per-byte, over an SPI bus) for the radio. Yes, unless you're doing something quite silly, the CPU cost of compression is almost always absolutely worth the benefit in terms of reduced transmission energy.

My question related to the fraction of radio energy in TSCH that is consumed by data transmission/reception versus everything else (idle listening, guard periods, control frames, etc.

To give you a data point -- early low-power link layers continually transmitted a packet (or wakeup frame) until receiving an acknowledgement from the intended receiver. Receivers periodically wake up, listen if there's energy on the channel, and if so, stay awake for 2 packet times (in case they woke up just after the preamble of a packet). If there's no coordination between receiver and sender, this means a sender must send on average for 1/2 of a wakeup interval to deliver a packet. E.g., 0.5s. Clearly in such a protocol a few extra bytes doesn't matter in terms of energy. Of course, TSCH is much, much better than this, I only mention this protocol as a simple explanatory example -- but what's the actual number?

Phil