Energy Efficient Implementation of IETF Protocols on Constrained Devices
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|Authors||Zehn Cao , Xuan He , Matthias Kovatsch , Hui Tian|
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
Internet Engineering Task Force Z. Cao Internet-Draft China Mobile Intended status: Informational X. He Expires: January 15, 2014Hitachi (China) Research and Development Corpor M. Kovatsch ETH Zurich H. Tian China Academy of Telecommunication Research July 14, 2013 Energy Efficient Implementation of IETF Protocols on Constrained Devices draft-hex-lwig-energy-efficient-01 Abstract This document summarizes the problems and current practices of energy efficient protocol implementation on constrained devices, mostly about how to make the protocols within IETF scope behave energy friendly. This document also summarizes the impact of link layer protocol power saving behaviors to the upper layer protocols, so that they can coordinately make the system energy efficient. 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 January 15, 2014. 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 Cao, et al. Expires January 15, 2014 [Page 1] Internet-Draft Lwig Energy Efficient July 2013 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions used in this document . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. MAC and Radio Duty Cycling . . . . . . . . . . . . . . . . . 4 3.1. Power Save Services Provided by IEEE 802.11v . . . . . . 5 4. IP Adaption and Transport Layer . . . . . . . . . . . . . . . 6 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 7 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 7 7. Cross Layer Optimization . . . . . . . . . . . . . . . . . . 7 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction In many scenarios of embedded systems, the networked system is composed of many battery-powered devices. For example, in an environmental monitoring system or a temperature and humidity monitoring system in the data center, there are no always-on and handy sustained power supplies for the large number of small devices. In such deployment environments, it is necessary to optimize the energy consumption of the entire system, including computing, application layer behavior, and lower layer communication. Various research efforts have been spent on this "energy efficiency" problem. Most of this research has focused on how to optimize the system's power consumption regarding a certain deployment scenario or how could an exisiting network function such as routing or security be more energy-efficient. Only few efforts were spent on energy- efficient designs for IETF protocols and standardized network stacks for such constrained devices [I-D.kovatsch-lwig-class1-coap]. The IETF has developed a suite of Internet protocols suitable for such small devices, including 6LoWPAN [RFC6282], 6LoWPAN-ND Cao, et al. Expires January 15, 2014 [Page 2] Internet-Draft Lwig Energy Efficient July 2013 [RFC6775], RPL[RFC6550], and CoAP[I-D.ietf-core-coap]. This document tries to summarize the design considerations of making the IETF protocol suite as energy-efficient as possible. While this document does not provide detailed and systematic solutions to the energy efficiency problem, it summarizes the design efforts and analyzes the design space of this problem. After reviewing the energy-efficient design of each layer, an overall conclusion is summarized. Though the lower layer communication optimization is the key part of energy efficient design, the protocol design at the network and application layers is also important to make the device battery-friendly. 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] 1.2. Terminology The terminologies used in this document can be referred to [I-D.ietf-lwig-terminology]. 2. Overview The IETF has developed multiple protocols to enable end-to-end IP communication between constrained nodes and fully capable nodes. This work has witnessed the evolution of the traditional Internet protocol stack to a light-weight Internet protocol stack. As show in Figure 1 below, the IETF has developed CoAP as the application layer and 6LoWPAN as the adaption layer to run IPv6 over IEEE 802.15.4 and Bluetooth Low-Energy, with the support of routing by RPL and efficient neighbor discovery by 6LoWPAN-ND. +-----+ +-----+ +-----+ +------+ |http | | ftp | |SNMP | | COAP | +-----+ +-----+ +-----+ +------+ \ / / / \ +-----+ +-----+ +-----+ +-----+ | tcp | | udp | | tcp | | udp | +-----+ +-----+ ===> +-----+ +-----+ \ / \ / +-----+ +------+ +-------+ +------+ +-----+ | RTG |--| ipv6 |--|ICMP/ND| | ipv6 |---| rpl | +-----+ +------+ +-------+ +------+ +-----+ | | +-------+ +-------+ +----------+ Cao, et al. Expires January 15, 2014 [Page 3] Internet-Draft Lwig Energy Efficient July 2013 |MAC/PHY| |6lowpan|--|6lowpan-nd| +-------+ +-------+ +----------+ | +-------+ |MAC/PHY| +-------+ Figure 1: Traditional and Lighweight Internet Protocol Stack There are comprehensive measurements of wireless communication [Powertrace]. Below we list the energy consumption profile of the most common atom operations on a prevalent sensor node platform. The measurement was based on the Tmote Sky with ContikiMAC as the radio duty cycling algorithm. From the measurement, we can see that optimized transmissions and reception consume almost the same amount of energy. For IEEE 802.15.4 and UWB radios, transmitting is actually even cheaper than receiving. Only for broadcast and non- synchronized communication transmissions become costly in terms of energy because they need to flood the medium for a long time. +---------------------------------------+---------------+ | Activity | Energy (uJ) | +---------------------------------------+---------------+ | Broadcast reception | 178 | +---------------------------------------+---------------+ | Unicast reception | 222 | +---------------------------------------+---------------+ | Broadcast transmission | 1790 | +---------------------------------------+---------------+ | Non-synchronized unicast transmission | 1090 | +---------------------------------------+---------------+ | Synchronized unicast transmission | 120 | +---------------------------------------+---------------+ | Unicast TX to awake receiver | 96 | +---------------------------------------+---------------+ Figure 2: Power consumption of atom operations on the Tmote Sky with ContikiMAC 3. MAC and Radio Duty Cycling Cao, et al. Expires January 15, 2014 [Page 4] Internet-Draft Lwig Energy Efficient July 2013 In low-power wireless networks, communication and power consumption are intertwined. The communication device is typically the most power-consuming component, but merely refraining from transmissions is not enough to attain a low power consumption: the radio consumes as much power in listen mode as when actively transmitting, as show in Figure 2 . To reduce power consumption, the radio must be switched completely off -- duty-cycled -- as much as possible. ContikiMAC is a very typical Radio Duty Cycling protocol [ContikiMAC]. From the perspective of MAC&RDC, all upper layer protocols, such as routing, RESTful communication, adaption, and management flows, are all applications. Since the duty cycling algorithm is the key to energy-efficiency of the wireless medium, it synchronizes the TX/RX request from the higher layer. The MAC&RDC are not in the scope of the IETF, yet lower layer designers and chipset manufactures take great care of the problem. For the IETF protocol designers, however, it is good to know the behaviors of lower layers so that the designed protocols can work perfectly with them. Once again, the IETF protocols we are going to talk about in the following sections are the customers of the lower layer. If they want to get better service in a cooperative way, they should be considerative and understand each other. 3.1. Power Save Services Provided by IEEE 802.11v IEEE 802.11v defines mechanisms and services for power save of stations/nodes that include flexible multicast service (FMS), proxy ARP advertisement, extended sleep modes, traffic filtering. It would be useful if upper layer protocols knows such capabilities provided by the lower layer, so that they can coordinate with each other. These services include: Proxy ARP: The Proxy ARP capability enables an AP to indicate that the non-AP STA will not receive ARP frames. The Proxy ARP capability enables the non-AP STA to remain in power-save for longer periods of time. BSS Max Idle Period management enables an AP to indicate a time period during which the AP does not disassociate a STA due to non- receipt of frames from the STA. This supports improved STA power saving and AP resource management. FMS: A service in which a non-access point (non-AP) station (STA) can request a multicast delivery interval longer than the delivery Cao, et al. Expires January 15, 2014 [Page 5] Internet-Draft Lwig Energy Efficient July 2013 traffic indication message (DTIM) interval for the purposes of lengthening the period of time a STA may be in a power save state. Traffic Filtering Service (TFS): A service provided by an access point (AP) to a non-AP station (STA) that can reduce the number of frames sent to the non-AP STA by not forwarding individually addressed frames addressed to the non-AP STA that do not match traffic filters specified by the non-AP STA. Using the above services provided by the lower layer, the constrained nodes can achieve either client initiated power save (via TFS) or network assisted power save (Proxy-ARP, BSS Max Idel Period and FMS). Upper layer protocols would better synchronize with the parameters such as FMS interval and BSS MAX Idle Period, so that the wireless transmissions are not triggered periodically. 4. IP Adaption and Transport Layer 6LoWPAN is the adaption layer to run IPv6 over IEEE 802.15.4 MAC&PHY. It was born to fill the gap that the IPv6 layer does not support fragmentation and assembly of <1280-byte packets while IEEE 802.15.4 only supports a MTU of 127 bytes. IPv6 is the basis for the higher layer protocols, including both TCP/ UDP transport and applications. So they are quite ignorant of the transmission and reception behaviors, and are almost neutral to the energy-efficiency problem. What the network stack can optimize is to save the computing power. For example the Contiki implementation has multiple cross layer optimizations for buffers and energy management, e.g., the computing and validation of UDP/TCP checksums without the need of reading IP headers from a different layer. These optimizations are software implementation techniques, and out of the scope of IETF and the LWIG working group. The 6LoWPAN contributes to the energy-efficiency problem in two ways. First of all, it swaps computing with communication. 6LoWPAN applies compression of the IPv6 header. This means less amount of data will be handled by the lower layer, but both the sender and receiver should spend more computing power on the compression and decompression of the packets over the air. Secondly, the 6LoWPAN working group developed the energy-efficient Neigbor Discovery called 6LoWPAN-ND, which is an energy efficient replacement of the IPv6 ND in constrained environments. IPv6 Neighbor Discovery was not designed for non-transitive wireless links, as its heavy use of multicast makes it inefficient and sometimes impractical in a low- Cao, et al. Expires January 15, 2014 [Page 6] Internet-Draft Lwig Energy Efficient July 2013 power and lossy network. 6LoWPAN-ND describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low-power Wireless Personal Area Networks and similar networks. 5. Routing Protocols The routing protocol designed by the IETF for constrained environments is called RPL [RFC6550]. As a routing protocol, RPL has to exchange messages periodically and keep routing states for each destination. RPL is optimized for the many-to-one commununication pattern, where network nodes primarily send data towards the border router, but has provisions for any-to-any routing as well. The authors of the Powertrace tool studied the power profile of RPL. It devides the routing protocol into control and data traffic. The control channel uses ICMP messages to establish and maintain the routing states. The data channel is any application that uses RPL for routing packets. The study has shown that the power consumption of the control traffic goes down over time and data traffic stays relatively constant. The study also reflects that the routing protocol should keep the control traffic as low as possible to make it energy-friendly. 6. Application Layer CoAP [I-D.ietf-core-coap]was designed as a RESTful application protocol, connecting the services of smart devices to the World Wide Web. CoAP is not a chatty protocol, it provides basic communication services such as service discovery and GET/POST/PUT/DELETE methods with a binary header. The energy-efficient design is implicitly included in the CoAP protocol design. To reduce regular and frequent queries of the resources, CoAP provides an observe mode, in which the requester registers its interest of a certain resource and the responder will report the value whenever it was updated. This reduces the request reponse roundtrip while keeping information exchange a ubiquitous service. 7. Cross Layer Optimization Cao, et al. Expires January 15, 2014 [Page 7] Internet-Draft Lwig Energy Efficient July 2013 The cross layer optimization is a technique used in many scenarios.There are some technologies for power efficient optimization via PHY to Routing cross layer design [Cross-layer-Optimization]. In this research, cross-layer optimization frameworks have been developed to minimize the total power consumption or to maximize the utility-power tradeoff using cooperative diversity. Also a cross-layer design in multihop wireless networks is proposed for congestion control, routing and scheduling-\u002Din transport, network and link layers into a coherent framework [Cross-layer-design]. This method and thinking could be applied to the implementation of energy effective cross layer design. 8. Summary We find a summary section necessary although most IETF documents do not contain it. The points we would like to summarize are as follows. a. All Internet protocols, which are in the scope of the IETF, are customers of the lower layers (PHY, MAC, and Duty-cycling). In order to get a better service, the designers of higher layers should know them better. b. The IETF has developed multiple protocols for constrained networked devices. A lot of implicitly included design principles have been used in these protocols. c. The power trace analysis of different protocol operations showed that for radio-duty-cycled networks broadcasts should be avoided. Saving unnecessary states maintenance is also an effective method to be energy-friendly. 9. IANA Considerations This document has no IANA requests. 10. Security Considerations This document discusses the energy efficient protocol design, and does not incur any changes or challenges on security issues besides what the protocol specifications have analyzed. 11. References 11.1. Normative References Cao, et al. Expires January 15, 2014 [Page 8] Internet-Draft Lwig Energy Efficient July 2013 [Announcementlayer] Dunkels, A., "The Announcement Layer: Beacon Coordination for the Sensornet Stack. In Proceedings of EWSN 2011", . [ContikiMAC] Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol, SICS Technical Report T2011:13", December 2011. [Cross-layer-Optimization] Le, . and . Hossain, "Cross-Layer Optimization Frameworks for Multihop Wireless Networks Using Cooperative Diversity", July 2008. [Cross-layer-design] Chen, ., Low, ., and . Doyle, "Cross-layer design in multihop wireless networks", 2011. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-18 (work in progress), June 2013. [I-D.ietf-lwig-terminology] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained Node Networks", draft-ietf-lwig-terminology-05 (work in progress), July 2013. [I-D.kovatsch-lwig-class1-coap] Kovatsch, M., "Implementing CoAP for Class 1 Devices", draft-kovatsch-lwig-class1-coap-00 (work in progress), October 2012. [Powertrace] Dunkels, ., Eriksson, ., Finne, ., and . Tsiftes, "Powertrace: Network-level Power Profiling for Low-power Wireless Networks", March 2011. 11.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Cao, et al. Expires January 15, 2014 [Page 9] Internet-Draft Lwig Energy Efficient July 2013 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012. Authors' Addresses Zhen Cao (Ed.) China Mobile Xuanwumenxi Ave. No.32 Beijing 100871 P.R.China Email: email@example.com, firstname.lastname@example.org Xuan He Hitachi (China) Research and Development Corporation 301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District Beijing 100190 P.R.China Email: email@example.com Matthias Kovatsch ETH Zurich Universitaetstrasse 6 Zurich, CH-8092 Switzerland Email: firstname.lastname@example.org Hui Tian China Academy of Telecommunication Research Huayuanbeilu No.52 Beijing, Haidian District 100191 China Email: email@example.com Cao, et al. Expires January 15, 2014 [Page 10]