Internet DRAFT - draft-cao-lwig-syn-layer

draft-cao-lwig-syn-layer






Internet Engineering Task Force                                   Z. Cao
Internet-Draft                                              China Mobile
Intended status: Informational                                     Y. Ma
Expires: August 29, 2013                             Hitachi (China) R&D
                                                                 H. Tian
                                                        China Academy of
                                             Telecommunications Research
                                                       February 25, 2013


  Synchronization Layer: an Implementation Method for Energy Efficient
                              Sensor Stack
                      draft-cao-lwig-syn-layer-01

Abstract

   This document analyzes the problem of energy efficient protocol
   implementation, and proposes an energy efficient design of mulitiple
   protocols by utilizing a common shim layer to synchronize the packet
   receipt and transimission on a single node.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 29, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Cao, et al.              Expires August 29, 2013                [Page 1]

Internet-Draft         Lwig Synchronization Layer          February 2013


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Conventions used in this document . . . . . . . . . . . . . 3
   2.  Energy Consumption Analysis . . . . . . . . . . . . . . . . . . 3
   3.  Synchronization Layer Design  . . . . . . . . . . . . . . . . . 4
     3.1.  Synchronization Layer . . . . . . . . . . . . . . . . . . . 5
     3.2.  After Synchronization . . . . . . . . . . . . . . . . . . . 6
     3.3.  Cross layer Optimization  . . . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7






























Cao, et al.              Expires August 29, 2013                [Page 2]

Internet-Draft         Lwig Synchronization Layer          February 2013


1.  Introduction

   This document analyzes the problem of energy efficient protocol
   implementation.  And inspired by the idea originally proposed in
   [ref.dunkel], proposes an energy efficient design of mulitiple
   protocols by utilizing a common shim layer to synchronize the packet
   receipt and transimission on a single node.

   The idea is straightforward.  Because different protocol cyclings
   result into the frequent and out-of-order wake-up of the radio, the
   energy consumption would be high.  By utilizing a shim layer between
   different applicaiton-layer protocols and the MAC/Link layer, the
   sending and receiving behavior of different protocols can be
   synchronized, which will wake up the radio at a low frequency and
   conserve energy consumption on the sensor.

1.1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119]


2.  Energy Consumption Analysis

   Chipset normally provides different modes of operation that consume
   different levels of energy.  There are normally three modes of
   operation on a wireless chipset.

   Transmit mode:  The mode at a node when transmitting a packet.

   Receive mode:   The mode at a node when receiving a packet.

   Idle mode:   The mode generally used at a node with the node is
      neither transmitting nor receiving a packet.  This mode consumes
      power because the node has to listen to the wireless medium
      continuously in order to detect a packet that it should receive,
      so that the node can then switch into receive mode.

   Sleep mode:  Sleep mode has very low power consumption.  The network
      interface at a node in sleep mode can neither transmit nor receive
      packets; the network interface must be woken up to idle mode first
      by an explicit instruction from the node.

   Sleep mode is the most energy efficient mode.  Some transceivers
   provide different levels of sleeping mode.  For example, CC3530
   provides three of them, PM1, PM2 and PM3, according to its
   specificaiton.  PM3 is the most efficient mode of them.



Cao, et al.              Expires August 29, 2013                [Page 3]

Internet-Draft         Lwig Synchronization Layer          February 2013


   Some research studies the energy efficiency of different operations
   on the sensor.  According to the investigation in [ref.icccn], the
   energy consumption of different operations are as follows.

   Operation
            /\
       Hum  |*
       Temp |**
       AES  |******
            |
     RX(10B)|***********************
            |
     TX(10B)|*******************************************************
            +-------------------------------------------------------->
                                                Energy Consumption (uJ)

   From this analysis we can clearly see that the most energy efficient
   way is to keep the sensor transciever sleep as much as possible.


3.  Synchronization Layer Design

   The key optimization direction is to reduce the frequency of radio
   wakeup.  But if there are multiple protocols running on a sensor
   node, the situation is unavoidable.  For example, as depicted in
   Figure 1 , there are three protocols running on a sensor node.  The
   three protocols have their different rate and phase of sending and/or
   receiving packets.  The figure shows an extreme case that their
   sending phases are totally un-overlapped.  In this case, the sensor
   radio stack should be active roughly 70% of time.  This makes the
   sensor stack not very energy efficient at all.

   The idea of handling this problem is to synchronize the transmission
   of different protocols.  We will introduce the synchronization layer
   and its impact in the following subsections.
















Cao, et al.              Expires August 29, 2013                [Page 4]

Internet-Draft         Lwig Synchronization Layer          February 2013


          /|
   Prtl1   |       __             __
           |      |  |           |  |
           |______|  |___________|  |__________
   Prtl2   |          __              __
           |         |  |            |  |
           |_________|  |____________|  |_________
   Prtl3   |              __              __
           |             |  |            |  |
           |_____________|  |____________|  |_______
   Radio   |       _________       _________
           |      |         |     |         |
           |______|         |_____|         |__________
           |-------------------------------------------------->
                                                           Time

               Figure 1: Radio Wakeup for multiple protocols

3.1.  Synchronization Layer

   The synchronization layer is set between the application protocols
   and MAC/Phy layer.  The Syn-layer provides API to the upper layer
   protocols and has its own frequency of sending and receiving packets.

   After synchronization, the protocol's transceiving behavior has been
   adapted.  The synchronization layer keeps its own clock and will wake
   up the radio once the clock times up.
       +-------+           +-------+           +-------+
       | Prtl1 |           | Prtl2 |           | Prtl3 |
       +-------+           +-------+           +-------+
             \                 |                  /
              \_________       |       __________/
                        \      |      /
                  +-------------------------+
                  |         Syn Layer       |
                  +-------------------------+
                               ||
                  +-------------------------+
                  |      MAC/Phy Layer      |
                  +-------------------------+

                    Figure 2: The Synchronization Layer

   As envisioned, after synchronization, the protocol's realtime
   requirement will affected.  The protocol's behavior has been delayed
   until the Syn-layer's clock has been trigger.  To support the
   realtime communication requirement, we can utilize a design of the
   API between the application-layer protocol and the Syn-layer.  If the



Cao, et al.              Expires August 29, 2013                [Page 5]

Internet-Draft         Lwig Synchronization Layer          February 2013


   protocol in consideration has specific realtime requirement, it can
   specify this requirement in the API call function.

         // protocol can specify the realtime requirment in the API call
         Pull (Key, Flag)


3.2.  After Synchronization

   After the synchronization layer is implemented and enabled, the
   packet transceiver is synchronized.  As shown in Figure 3, the radio
   wakeup rate is reduced to about 30%.


   Prtl1   |       __             __
           |      |  |           |  |
           |______|  |___________|  |__________
   Prtl2   |          __              __
           |         |  |            |  |
           |_________|  |____________|  |_________
   Prtl3   |              __              __
           |             |  |            |  |
           |_____________|  |____________|  |________
   Radio   |       _________       _________
           |      |         |     |         |
           |______|         |_____|         |__________
           |                 ____              ____
   Syn     |                |    |            |    |
           |________________|    |____________|    |_____
           |
           +-------------------------------------------------->
                                                           Time

               Figure 3: Radio Wakeup for multiple protocols

3.3.  Cross layer Optimization

   After synchronization layer reduces radio wakeup rate, how to reduce
   the amount of transferred packet also should be considered.

   In current resource constrained device implementation, every layer
   has its own registration process.  For example, IEEE 802.15.4
   initialization at MAC layer, and resource registration for CoAP or
   other protocols at APP layer.  Thus these processes are hard to
   integrated, and lack of efficiency.

   The MAC layer and APP layer registration also can be implemented into
   same packet, the synchronization layer can further decrease the whole



Cao, et al.              Expires August 29, 2013                [Page 6]

Internet-Draft         Lwig Synchronization Layer          February 2013


   registration process transferred packet, as well the communication
   cost.


4.  IANA Considerations

   This document has no IANA requests.


5.  Security Considerations

   This document does not design any protocols or mechanisms, and hence
   does not introduce any security issues or challenges that need to be
   resolved further.


6.  References

6.1.  Normative References

   [ref.dunkel]
              Dunkels, A., "The Announcement Layer: Beacon Coordination
              for the Sensornet Stack. In Proceedings of EWSN 2011".

   [ref.icccn]
              Margi, C., "Impact of Operating Systems on Wireless Sensor
              Networks (Security) Applications and Testbeds, ICCCN
              2010".

6.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


Authors' Addresses

   Zhen Cao
   China Mobile
   Xuanwumenxi Ave. No. 32
   Beijing,   100871
   China

   Phone: +86-10-52686688
   Email: zehn.cao@gmail.com, caozhen@chinamobile.com






Cao, et al.              Expires August 29, 2013                [Page 7]

Internet-Draft         Lwig Synchronization Layer          February 2013


   Yuanchen Ma
   Hitachi (China) R&D
   301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District
   Beijing,   100190
   P.R.China

   Phone:
   Fax:
   Email: ycma@hitachi.cn
   URI:


   Hui Tian
   China Academy of Telecommunications Research
   Huayuanbeilu No.52
   Beijing,   100191
   P.R.China

   Phone:
   Fax:
   Email: tianhui@mail.ritt.com.cn
   URI:





























Cao, et al.              Expires August 29, 2013                [Page 8]