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

I think it is worthwhile to divide battery devices into two categories. Those with consumer accessible batteries (think home thermostat or temperature sensors) and those with embedded batteries (gas or water meters). Where typical lifetimes for the first being generally accepted as 3+ years the second is at least 10 and more commonly 20 years. Jari's example of 100 devices in the home gets really onerous when you think of a utility with 5,000,000 meters to manage. The cost of a homeowner changing a battery is a couple of bucks, the cost to change a gas meter battery is measured in hundreds of dollars.

Gene Falendysz
Phone: (864) 718.6676
Fax: (864) 718.6871

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Jari Arkko
Sent: Monday, March 05, 2012 6:00 AM
To: Angelo P. Castellani
Cc: core WG
Subject: Re: [core] sleepy to sleepy communication I-Ds

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" <angelo@castellani.net> 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 <jari.arkko@piuha.net> 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
>>
>>
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core