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

[Jari Arkko <[e-mail]>]

I worry about creating lots of infrastructure, too. But I also see many architectures that are device-server-user/app, and for those there wouldn't necessarily be any impact.

Not all link layers and devices can get to 3 years, actually far from it. Yet we propably want to use those for many reasons, including coverage (cellular) and existing APs (wlan).

And I think 3 years is far from enough. I have 100 devices at home, and if they had even a 10 year battery lifetime, I'd still change a battery per month.

So I think we still have plenty of work left. At least on some parts; not claiming that this necessarily means something for the CORE WG.

Jari

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

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