[recipe] Sleeping Nodes

[Hannes Tschofenig <[e-mail]>]

Hi all, 

in the recently published report from the Smart Object Workshop we have section about "sleeping nodes":
http://tools.ietf.org/html//draft-iab-smart-object-workshop-01#section-3.2

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 http://www.iab.org/wp-content/IAB-uploads/2011/04/Wasserman.ppt. 
You may also find her paper "IT’S NOT EASY BEING 'GREEN'"  interesting:  
http://www.iab.org/wp-content/IAB-uploads/2011/03/Wasserman.pdf

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. 

Ciao
Hannes

--------

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.