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

"Dijk, Esko" <esko.dijk@philips.com> Tue, 13 March 2012 13:19 UTC

Return-Path: <esko.dijk@philips.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2796621F86CA for <core@ietfa.amsl.com>; Tue, 13 Mar 2012 06:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.028
X-Spam-Level:
X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RhkjqGpZgPY for <core@ietfa.amsl.com>; Tue, 13 Mar 2012 06:19:47 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id EAFF021F86C2 for <core@ietf.org>; Tue, 13 Mar 2012 06:19:46 -0700 (PDT)
Received: from mail119-db3-R.bigfish.com (10.3.81.248) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 13 Mar 2012 13:19:46 +0000
Received: from mail119-db3 (localhost [127.0.0.1]) by mail119-db3-R.bigfish.com (Postfix) with ESMTP id 919B56006D; Tue, 13 Mar 2012 13:19:46 +0000 (UTC)
X-SpamScore: -58
X-BigFish: VPS-58(zz217bL15d6O9371I9251J542M1432N98dKef7Rzz1202hzz8275ch1033IL8275dhz2dh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
Received: from mail119-db3 (localhost.localdomain [127.0.0.1]) by mail119-db3 (MessageSwitch) id 133164478582995_20724; Tue, 13 Mar 2012 13:19:45 +0000 (UTC)
Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.248]) by mail119-db3.bigfish.com (Postfix) with ESMTP id 0F8E414004D; Tue, 13 Mar 2012 13:19:45 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 13 Mar 2012 13:19:41 +0000
Received: from 011-DB3MMR1-023.MGDPHG.emi.philips.com (10.128.28.107) by 011-DB3MMR1-003.MGDPHG.emi.philips.com (10.128.28.53) with Microsoft SMTP Server (TLS) id 14.1.355.3; Tue, 13 Mar 2012 13:21:47 +0000
Received: from 011-DB3MPN1-014.MGDPHG.emi.philips.com ([169.254.4.162]) by 011-DB3MMR1-023.MGDPHG.emi.philips.com ([fe80::e485:97aa:9b41:86e3%11]) with mapi id 14.01.0355.003; Tue, 13 Mar 2012 13:21:46 +0000
From: "Dijk, Esko" <esko.dijk@philips.com>
To: Zhen Cao <zehn.cao@gmail.com>, "Angelo P. Castellani" <angelo@castellani.net>
Thread-Topic: [core] sleepy to sleepy communication I-Ds
Thread-Index: AQHM9yvFF4vhgW3HcE6AjepfFzvAB5Zat50AgAB7rICAACz3gIAAEs0AgAACvoCAAy6YAIAJpH1A
Date: Tue, 13 Mar 2012 13:21:46 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED61807B391@011-DB3MPN1-014.MGDPHG.emi.philips.com>
References: <9032C193-A015-4F41-B441-4D1D47594FC9@koanlogic.com> <4F53E746.7050401@piuha.net> <9B51E46C-D03D-4911-8D00-65B56DE48F63@koanlogic.com> <CAPxkH3jC3iznkVTRnYneVw2dny=HvS0gn3PaQ2KHJ-jmX55s0A@mail.gmail.com> <4F548482.9070707@piuha.net> <CAPxkH3i5aky4bH-NXsFN462xxPBm3X0knG5C9gGf8ZtXKboWFQ@mail.gmail.com> <CAProHASm6+Q_nBR69gSLh=wqXbBbR=6RBs-Oa0bwtBpv393M=w@mail.gmail.com>
In-Reply-To: <CAProHASm6+Q_nBR69gSLh=wqXbBbR=6RBs-Oa0bwtBpv393M=w@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [194.171.252.101]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: core WG <core@ietf.org>
Subject: Re: [core] sleepy to sleepy communication I-Ds
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2012 13:19:48 -0000

Typical industry requirements for battery-powered wireless sensors are in the order of 7-10 years, from what I know.
So certainly tighter requirements.

Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zhen Cao
Sent: Wednesday 7 March 2012 11:02
To: Angelo P. Castellani
Cc: core WG
Subject: Re: [core] sleepy to sleepy communication I-Ds

On Mon, Mar 5, 2012 at 5:26 PM, 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?

Are you sure about the battery lifetime? I am using two AA battery
with 700mAH each. And the power consumption of the RF module is 23mA,
21uA, 1uA for active, idle and sleep.  So normally for me it is
several month at most.

Best regards,
Zhen


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



--
Best regards,
Zhen
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.