Re: [recipe] Sleeping Nodes

Juergen Quittek <> Fri, 15 July 2011 08:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B378721F879F for <>; Fri, 15 Jul 2011 01:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.169
X-Spam-Status: No, score=-102.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7GqbEe9aFzZ7 for <>; Fri, 15 Jul 2011 01:31:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D45EB21F85AE for <>; Fri, 15 Jul 2011 01:31:52 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 17BF72800032F; Fri, 15 Jul 2011 10:31:52 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YPHeF2-LHxpL; Fri, 15 Jul 2011 10:31:52 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id E6EFB2800032C; Fri, 15 Jul 2011 10:31:41 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Fri, 15 Jul 2011 10:31:41 +0200
From: Juergen Quittek <>
To: Hannes Tschofenig <>, "" <>
Thread-Topic: [recipe] Sleeping Nodes
Thread-Index: AQHMQrnBIbi3RjzIFkirxjS0C48+p5TtBPkA
Date: Fri, 15 Jul 2011 08:31:40 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <0FC52F4950793243A1E672D869B531CE@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [recipe] Sleeping Nodes
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RECIPE \(Reducing Energy Consumption with Internet Protocols Exploration\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Jul 2011 08:31:57 -0000

Dear Hannes,

Thanks for reviving this list and pointing to Magaret's slides.

There is another extensive discussion of sleeping nodes in the keynote
that energy-saving pioneer Rajesh Gupta gave 2009 at the 2nd workshop of
the IEEE Green Communications
Workshop series at ICC and GlobeCom (



On 15.07.11 08:37, "Hannes Tschofenig" <> wrote:

>Hi all, 
>in the recently published report from the Smart Object Workshop we have
>section about "sleeping nodes":
>Given the scope of this group you may find the writeup interesting.
>The writeup was based on the discussions at the workshop following
>Margaret's presentation, which can found here
>You may also find her paper "IT¹S NOT EASY BEING 'GREEN'"  interesting:
>While Margaret talked a lot about ND I am wondering whether someone of
>you had looked into energy efficiency of other protocols already as well.
>3.2.  Sleep Modes
>   One limitation of smart objects is the available energy.  To extend
>   battery life, for example of a watch battery or single AAA battery
>   for months, these small, low power devices have to sleep from 99% to
>   99.5% of their time.  For example, a light sensor may wake up to
>   check whether it is night-time to turn on light bulbs.  Most parts of
>   the system are off-line most of the time and particularly
>   communication components are put into a sleeping state (e.g., WLAN
>   radio interface) and only very few components of an embedded system
>   board, such as sensors, are triggered periodically.  When interesting
>   events happen then these components wake-up other parts of the
>   system, for example a radio interface to connect to the Internet.
>   Every bit is precious, so is every round trip, and every millisecond
>   of radio activity.
>   Many IETF protocols implicitly assume that nodes in a network are
>   always-on and respond to messages, i.e., to maintain a persistent
>   presence on the network in order to respond to periodic messages that
>   are required in order to maintain persistent sessions, connections,
>   security associations, or state.  These protocols work well on
>   networks with sufficient network bandwidth, where there is a low cost
>   to receiving/sending messages, and nodes are persistently available
>   on the network.
>   In the early days a machine had gotten a specific IP address
>   allocated and it could use it when it wanted to send an IP packet.
>   You might need to execute an ARP exchange first before sending the
>   packet but you could keep the mapping in the cache for 15 minutes.
>   Nowadays we want to make sure that we are on the right network before
>   we send an IP packet, we run neighbor discovery, we cannot keep
>   neighbor discovery for 15 minutes and so when a node wakes up again
>   it essentially has to re-do it to refresh the cache, we want to run
>   Detecting Network Attachment (DNA) procedures to check that hosts are
>   on the same network either by re-getting an address using the Dynamic
>   Host Configuration Protocol (DHCP) or by noticing that the node is
>   using the same default gateway because of a received Router
>   Advertisement (RA).  Essentially, a number of steps have to be taken
>   before sending a packet.
>   However, these protocols do not work well, if at all, when the cost
>   of sending/receiving those messages is high (in terms of bandwidth or
>   battery life) or in cases where nodes sleep periodically and are not
>   persistently available to receive those messages.  A number of issue
>   arise from these almost-always-off nodes.
>   Also a lot of our protocols are getting more chatty.  Keeping the
>   receiver up for an additional roundtrip costs extra energy.  Protocol
>   messages can also be lengthy, e.g., many protocols carry XML-based
>   payloads.
>   There are a couple of ways to think about how to make the situation
>   less worse:
>   1.  The Always-On Assumption
>       When designing a protocol that assumes that the nodes will always
>       be there at least consider an alternative paradigm.  For example,
>       with duplicate address detection an alternative would be not to
>       use it.  There might be also the option to consider an
>       architecture with a proxy node that these nodes can poll when
>       they boot up to find out whether anyone tried to contact them or
>       whether anything they care about has happened, or the proxy
>       answers on behalf of another node.
>   2.  High Cost to Rejoin the Network
>       The goal of these things is to determine whether a wireless node
>       is not moved to another network while it was asleep and that
>       might be a viable thing to do.  Expecting a wirelss node to go
>       through all these steps every time it wakes up before it is
>       allowed to send an Ip packet could be considered rather
>       excessive.
>       Can we find ways to reduce the number of protocol interactions
>       that have to be executed for network attachment, including
>       determining whether a node has moved or the environment has
>       changed otherwise?
>   3.  Verbose Protocols
>       Some protocols involve multiple roundtrips and/or lengthy
>       messages.  As a result, low-powered nodes have to use more power
>       in sending messages and have to stay powered on for a longer
>       period of time as they wait for the protocol exchanges to
>       complete.  The best way to address these problems is to ensure
>       that the simplest possible protocol exchanges are used when the
>       protocols in question are designed.  However, in some cases
>       alternative encoding formats and compression may also help.
>   One can argue that certain features are not useful in an environment
>   where most nodes are sleeping.  The main focus of past investigations
>   has been on IPv6 and ND but other protocols do also deserve a deeper
>   investigation, such as DNS, and DHCP.
>   During the protocol design phase certain protocols were assumed to be
>   used in a human-to-device context and therefore it was argued that
>   the verbose encoding is helpful.  Examples are the Hypertext Transfer
>   Protocol (HTTP), the Session Initiation Protocol (SIP), and
>   Extensible Messaging and Presence Protocol (XMPP).  Nowadays these
>   protocols are also being considered and used in device-to-device
>   communication and the verbose nature is not helpful.
>   While the principles seem to be most useful for low-power, battery
>   powered devices they would also be useful for other devices as well.
>   Energy efficiency is useful for normal devices as well, such as
>   laptops and smart phones.
>   For example, consider energy consumption in a home environment.  The
>   question is whether it will save more energy than it uses and
>   therefore one has to consider the overall energy consumption of the
>   entire solution.  This is not always an easy question to answer.
>   IEEE 802.11 nodes, for example, use a lot of power if they cannot be
>   made to sleep most of the time.  A light bulb may use less power but
>   there is also the device that controls the bulb that may consume a
>   lot of energy all the time.  In total, more energy may be consumed
>   when considering these two devices together.
>recipe mailing list