Re: [core] sleepy to sleepy communication I-Ds

["Angelo P. Castellani" <[e-mail]>]

I agree with you that this can save a lot more of energy, if the hosts
can provide service during theirs "office hours" :)

However if the nodes will behave in such a way, for sure this will be
visible to the clients and lots of infrastructure (proxies) will be
required to get anything usable by the users.

With regular sensor networks duty cycling, a ~3 years lifetime is
feasible with regular batteries (depending upon actual usage and
network traffic). Are you targeting a use case with tighter
requirements?

Best,
Angelo

On Mon, Mar 5, 2012 at 10:16, Jari Arkko <[e-mail]> wrote:
>
> Angelo,
>
>
>> Indeed sensor networks support sleeping using radio duty cycling at
>> lower layers, this turns out in having the sleeping functionality
>> without any loss of communication at the upper layers.
>>
>
> We discussed this a couple of IETFs back. Since then I've been doing some
> talking to our researchers who measure and improve power usage in radios.
>
> First, duty cycling is already pretty widely used for radio technology. All
> cellular systems, for instance, turn off the radio except in during the time
> they listen for possible incoming paging signals, system information
> necessary to stay in contact at all, or when they have been granted a time
> slot to send.
>
> Secondly and more importantly, per their measurements, even after all the
> above techniques, periodic listening for possibly incoming messages is the
> biggest consumer of energy in applications where we'd like to have a long
> battery life, such as in sensors. That power usage dwarfs everything else,
> so it has to come down, somehow, to make an improvement.
>
> So if we want to achieve significantly longer battery lifetimes (and I claim
> we need those) we need to change some things. Obviously a lot of the link
> layers can be tuned better, implementing simply longer paging frequencies,
> for instance. My hypothesis is that we'll have to go longer than what
> typical application protocol timeouts are today, so the change would be
> something that is visible to applications. We could change some of the
> timeouts, but it is not clear that network buffers and all underlying
> mechanisms deployed today support those without changes. And in general, I
> think it is better to fit the communication model to the problem at hand
> than vice versa. As a result, I personally believe that we need to build
> applications that natively communicate in ways that make sleep modes easy.
> Such as publish-subscribe instead of direct request-response from anyone who
> needs the information. But like I said, this is a hypothesis and I'd love to
> be proven wrong.
>
> Jari
>
>