Internet DRAFT - draft-hex-lwig-energy-efficient
draft-hex-lwig-energy-efficient
Internet Engineering Task Force Z. Cao
Internet-Draft China Mobile
Intended status: Informational X. He
Expires: April 24, 2014Hitachi (China) Research and Development Corporat
M. Kovatsch
ETH Zurich
H. Tian
China Academy of Telecommunication Research
C. Gomez
Universitat Politecnica de Catalunya/i2CAT
October 21, 2013
Energy Efficient Implementation of IETF Constrained Protocol Suite
draft-hex-lwig-energy-efficient-02
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 April 24, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Cao, et al. Expires April 24, 2014 [Page 1]
Internet-Draft Lwig Energy Efficient October 2013
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
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
3.2. Power Save Services Provided by Bluetooth Low Energy . . 6
3.3. Power Save Services in IEEE 802.15.4 . . . . . . . . . . 7
4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 7
5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 8
6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 8
7. Cross Layer Optimization . . . . . . . . . . . . . . . . . . 9
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
In many scenarios, the network systems comprises many battery-powered
or energy-harvesting 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 existing network function such as routing or security be
Cao, et al. Expires April 24, 2014 [Page 2]
Internet-Draft Lwig Energy Efficient October 2013
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],[RFC6775],[RFC4944]
), 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 |
+-----+ +-----+ ===> +-----+ +-----+
Cao, et al. Expires April 24, 2014 [Page 3]
Internet-Draft Lwig Energy Efficient October 2013
\ / \ /
+-----+ +------+ +-------+ +------+ +-----+
| RTG |--| ipv6 |--|ICMP/ND| | ipv6 |---| rpl |
+-----+ +------+ +-------+ +------+ +-----+
| |
+-------+ +-------+ +----------+
|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 April 24, 2014 [Page 4]
Internet-Draft Lwig Energy Efficient October 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 (RDC) protocol [ContikiMAC].
From the perspective of MAC&RDC, all upper layer protocols, such as
routing, RESTful communication, adaptation, 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
considerate and understand each other.
3.1. Power Save Services Provided by IEEE 802.11v
IEEE 802.11v [IEEE80211v] 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 Access Point (AP) to
indicate that the non-AP station (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.
Basic Service Set (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.
Cao, et al. Expires April 24, 2014 [Page 5]
Internet-Draft Lwig Energy Efficient October 2013
FMS: A service in which a non-access point (non-AP) station (STA) can
request a multicast delivery interval longer than the delivery
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.
3.2. Power Save Services Provided by Bluetooth Low Energy
Bluetooth Low Energy (BT-LE) is a wireless low-power communications
technology that is the hallmark component of the Bluetooth 4.0
specification. BT-LE has been designed for the goal of ultra-low-
power consumption. Currently, it is possible to run IPv6 over BT-LE
networks by using a 6LoWPAN variant adapted to BT-LE
[I-D.ietf-6lowpan-btle].
BT-LE networks comprise a master and one or more slaves which are
connected to the master. The BT-LE master is assumed to be a
relatively powerful device, whereas a slave is typically a
constrained device (e.g. a class 1 device).
Medium access in BT-LE is based on a TDMA scheme which is coordinated
by the master. This device determines the start of connection
events, in which communication between the master and a slave takes
place. At the beginning of a connection event, the master sends a
poll message, which may encapsulate data, to the slave. The latter
must send a response, which may also contain data. The master and
the slave may continue exchanging data until the end of the
connection event. The next opportunity for communication between the
master and the slave will be in the next connection event scheduled
for the slave.
The time between consecutive connection events is defined by the
connInterval parameter, which may range between 7.5 ms and 4 s. The
slave may remain in sleep mode since the end of its last connection
event until the beginning of its next connection event. Therefore,
Cao, et al. Expires April 24, 2014 [Page 6]
Internet-Draft Lwig Energy Efficient October 2013
BT-LE is duty-cycled by nature. Furthermore, after having replied to
the master, a slave is not required to listen to the master (and thus
may keep the radio in sleep mode) for connSlaveLatency consecutive
connection events. connSlaveLatency is an integer parameter between 0
and 499 which should not cause link inactivity for more than
connSupervisionTimeout time. The connSupervisionTimeout parameter is
in the range between 100 ms and 32 s.
Upper layer protocols should take into account the medium access and
duty-cycling behavior of BT-LE. In particular, connInterval,
connSlaveLatency and connSupervisionTimeout determine the time
between two consecutive connection events for a given slave. The
upper layer packet generation pattern and rate should be consistent
with the settings of the aforementioned parameters (and vice versa).
3.3. Power Save Services in IEEE 802.15.4
To be added.
4. IP Adaptation 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
lower layers, 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 Neighbor Discovery
called 6LoWPAN-ND, which is an energy efficient replacement of the
IPv6 ND in constrained environments. IPv6 Neighbor Discovery was not
Cao, et al. Expires April 24, 2014 [Page 7]
Internet-Draft Lwig Energy Efficient October 2013
designed for non-transitive wireless links, as its heavy use of
multicast makes it inefficient and sometimes impractical in a low-
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. However, 6LoWPAN ND does not modify Neighbor
Unreachability Detection (NUD) timeouts, which are very short (by
default three transmissions spaced one second apart). NUD timeout
settings should be tuned taking into account the latency that may be
introduced by duty-cycled mechanisms at the link layer, or
alternative, less impatient NUD algorithms should be considered
[I-D.ietf-6man-impatient-nud].
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 communication
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 [Powertrace] studied the power
profile of RPL. It divides 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. The amount of RPL control traffic can be
tuned by setting the Trickle algorithm parameters (i.e. Imin, Imax
and k) to adequate values. However, there exists a trade-off between
energy consumption and other performance parameters such as network
convergence time and robustness.
Todo: more discussion of energy efficient routing.
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
Cao, et al. Expires April 24, 2014 [Page 8]
Internet-Draft Lwig Energy Efficient October 2013
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
response roundtrip while keeping information exchange a ubiquitous
service.
CoAP offers mechanisms for reliable communication between two CoAP
endpoints. A CoAP message may be signaled as a confirmable (CON)
message, and an acknowledgment (ACK) is issued by the receiver if the
CON message is correctly received. The sender starts a
Retransmission TimeOut (RTO) for every CON message sent. The initial
RTO value is chosen randomly between 2 and 3 s. If an RTO expires,
the new RTO value is doubled (unless a limit on the number of
retransmissions has been reached). Since duty-cycling at the link
layer may lead to large latencies (i.e. even greater than the initial
RTO value), CoAP RTO parameters should be tuned accordingly in order
to avoid spurious RTOs which would unnecessarily waste node energy
and other resources.
7. Cross Layer Optimization
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 trade-off using
cooperative diversity.
Also a cross-layer design in multihop wireless networks is proposed
for congestion control, routing and scheduling - in 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.
Todo: more discussion of Cross layer issues.
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.
Cao, et al. Expires April 24, 2014 [Page 9]
Internet-Draft Lwig Energy Efficient October 2013
b. The IETF has developed multiple protocols for constrained
networked devices. A lot of implicit energy efficient 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. Acknowledgments
Carles Gomez has been supported by Ministerio de Economia y
Competitividad and FEDER through project TEC2012-32531.
10. IANA Considerations
This document has no IANA requests.
11. 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.
12. References
12.1. Normative References
[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-6lowpan-btle]
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
Cao, et al. Expires April 24, 2014 [Page 10]
Internet-Draft Lwig Energy Efficient October 2013
over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12
(work in progress), February 2013.
[I-D.ietf-6man-impatient-nud]
Gashinsky, I. and E. Nordmark, "Neighbor Unreachability
Detection is too impatient", draft-ietf-6man-impatient-
nud-06 (work in progress), April 2013.
[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.
[IEEE80211v]
IEEE, ., "Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) specifications, Amendment
8: IEEE 802.11 Wireless Network Management.", February
2012.
[Powertrace]
Dunkels, ., Eriksson, ., Finne, ., and . Tsiftes,
"Powertrace: Network-level Power Profiling for Low-power
Wireless Networks", March 2011.
12.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
Cao, et al. Expires April 24, 2014 [Page 11]
Internet-Draft Lwig Energy Efficient October 2013
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
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: zehn.cao@gmail.com, caozhen@chinamobile.com
Xuan He
Hitachi (China) Research and Development Corporation
301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District
Beijing 100190
P.R.China
Email: xhe@hitachi.cn
Matthias Kovatsch
ETH Zurich
Universitaetstrasse 6
Zurich, CH-8092
Switzerland
Email: kovatsch@inf.ethz.ch
Hui Tian
China Academy of Telecommunication Research
Huayuanbeilu No.52
Beijing, Haidian District 100191
China
Email: tianhui@mail.ritt.com.cn
Cao, et al. Expires April 24, 2014 [Page 12]
Internet-Draft Lwig Energy Efficient October 2013
Carles Gomez
Universitat Politecnica de Catalunya/i2CAT
C/Esteve Terradas, 7
Castelldefels 08860
Spain
Email: carlesgo@entel.upc.edu
Cao, et al. Expires April 24, 2014 [Page 13]
