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]