draft-ietf-lwig-cellular-02.txt   draft-ietf-lwig-cellular-03.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft A. Eriksson Internet-Draft A. Eriksson
Intended status: Informational A. Keranen Intended status: Informational A. Keranen
Expires: February 14, 2015 Ericsson Expires: April 30, 2015 Ericsson
August 13, 2014 October 27, 2014
Building Power-Efficient CoAP Devices for Cellular Networks Building Power-Efficient CoAP Devices for Cellular Networks
draft-ietf-lwig-cellular-02 draft-ietf-lwig-cellular-03
Abstract Abstract
This memo discusses the use of the Constrained Application Protocol This memo discusses the use of the Constrained Application Protocol
(CoAP) protocol in building sensors and other devices that employ (CoAP) protocol in building sensors and other devices that employ
cellular networks as a communications medium. Building communicating cellular networks as a communications medium. Building communicating
devices that employ these networks is obviously well known, but this devices that employ these networks is obviously well known, but this
memo focuses specifically on techniques necessary to minimize power memo focuses specifically on techniques necessary to minimize power
consumption. consumption.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 14, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This memo discusses the use of the Constrained Application Protocol This memo discusses the use of the Constrained Application Protocol
(CoAP) protocol [I-D.ietf-core-coap] in building sensors and other (CoAP) protocol [RFC7252] in building sensors and other devices that
devices that employ cellular networks as a communications medium. employ cellular networks as a communications medium. Building
Building communicating devices that employ these networks is communicating devices that employ these networks is obviously well
obviously well known, but this memo focuses specifically on known, but this memo focuses specifically on techniques necessary to
techniques necessary to minimize power consumption. CoAP has many minimize power consumption. CoAP has many advantages, including
advantages, including being simple to implement; a thousand lines for being simple to implement; a thousand lines for the entire software
the entire software above IP layer is plenty for a CoAP-based sensor, above IP layer is plenty for a CoAP-based sensor, for instance.
for instance. However, while many of these advantages are obvious However, while many of these advantages are obvious and easily
and easily obtained, optimizing power consumption remains challenging obtained, optimizing power consumption remains challenging and
and requires careful design [I-D.arkko-core-sleepy-sensors]. requires careful design [I-D.arkko-core-sleepy-sensors].
The memo targets primarily 3GPP cellular networks in their 2G, 3G, The memo targets primarily 3GPP cellular networks in their 2G, 3G,
and LTE variants and their future enhancements, including possible and LTE variants and their future enhancements, including possible
power efficiency improvements at the radio and link layers. The power efficiency improvements at the radio and link layers. The
exact standards or details of the link layer or radios are not exact standards or details of the link layer or radios are not
relevant for our purposes, however. To be more precise, the material relevant for our purposes, however. To be more precise, the material
in this memo is suitable for any large-scale, public network that in this memo is suitable for any large-scale, public network that
employs point-to-point communications model and radio technology. employs point-to-point communications model and radio technology.
Our focus is devices that need to be optimized for power usage, and Our focus is devices that need to be optimized for power usage, and
skipping to change at page 4, line 47 skipping to change at page 4, line 47
| Mains | Always-on | Always-on | Always-on | | Mains | Always-on | Always-on | Always-on |
| | | | | | | | | |
+------------+----------------+------------------+-----------------+ +------------+----------------+------------------+-----------------+
Figure 1: Power usage strategies for different classes of Figure 1: Power usage strategies for different classes of
applications applications
Many of these situations lead to a requirement for minimizing power Many of these situations lead to a requirement for minimizing power
usage and/or maximizing battery lifetimes. A summary of the usage and/or maximizing battery lifetimes. A summary of the
different situations for sensor-type devices, using the power usage different situations for sensor-type devices, using the power usage
strategies described in [I-D.ietf-lwig-terminology], is shown in strategies described in [RFC7228], is shown in Figure 1.
Figure 1. Unfortunately, much of our current technology has been Unfortunately, much of our current technology has been built with
built with different objectives in mind. Networked devices that are different objectives in mind. Networked devices that are "always
"always on", gadgets that require humans to recharge them every on", gadgets that require humans to recharge them every couple of
couple of days, and protocols that have been optimized to maximize days, and protocols that have been optimized to maximize throughput
throughput rather than conserve resources. rather than conserve resources.
Long battery lifetimes are required for many applications, however. Long battery lifetimes are required for many applications, however.
In some cases these lifetimes should be in the order of years or even In some cases these lifetimes should be in the order of years or even
a decade or longer. Some communication devices already reach multi- a decade or longer. Some communication devices already reach multi-
year lifetimes, and continuous improvement in low-power electronics year lifetimes, and continuous improvement in low-power electronics
and advances in radio technology keep pushing these lifetimes longer. and advances in radio technology keep pushing these lifetimes longer.
However, it is perhaps fair to say that battery lifetimes are However, it is perhaps fair to say that battery lifetimes are
generally too short at present time. generally too short at present time.
Power usage can not be evaluated solely based on lower layer Power usage can not be evaluated solely based on lower layer
skipping to change at page 7, line 42 skipping to change at page 7, line 42
often the device needs to wake-up for paging messages, and more crude often the device needs to wake-up for paging messages, and more crude
mechanisms where the device simply disconnects from the network for a mechanisms where the device simply disconnects from the network for a
period of time. There are associated costs and benefits to each period of time. There are associated costs and benefits to each
method, but those are not relevant for this memo, as long as some method, but those are not relevant for this memo, as long as some
control method exists. control method exists.
4. Scenarios 4. Scenarios
Not all applications or situations are equal. They may require Not all applications or situations are equal. They may require
different solutions or communication models. This memo focuses on different solutions or communication models. This memo focuses on
two common scenarios: two common scenarios at cellular networks:
Real-Time Reachable Devices Real-Time Reachable Devices
This scenario involves all communication that requires real-time This scenario involves all communication that requires real-time
or near real-time communications with a device. That is, a or near real-time communications with a device. That is, a
network entity must be able to reach the device with a small time network entity must be able to reach the device with a small time
lag at any time, and no pre-agreed wake-up schedule can be lag at any time, and no pre-agreed wake-up schedule can be
arranged. By "real-time" we mean any reasonable end-to-end arranged. By "real-time" we mean any reasonable end-to-end
communications latency, be it measured in milliseconds or seconds. communications latency, be it measured in milliseconds or seconds.
However, unpredictable sleep states are not expected. However, unpredictable sleep states are not expected.
skipping to change at page 8, line 47 skipping to change at page 8, line 47
existence of the device is typically not immediately obvious to the existence of the device is typically not immediately obvious to the
other nodes participating in the application. As discussed earlier, other nodes participating in the application. As discussed earlier,
multicast discovery has limited value in public networks; network multicast discovery has limited value in public networks; network
nodes cannot practically discover individual devices in a large nodes cannot practically discover individual devices in a large
public network. And the devices can not discover who they need to public network. And the devices can not discover who they need to
talk, as the public network offers just basic Internet connectivity. talk, as the public network offers just basic Internet connectivity.
Our recommendation is to initiate a discovery and registration Our recommendation is to initiate a discovery and registration
process. This allows each device to inform its peers that it has process. This allows each device to inform its peers that it has
connected to the network and that it is reachable at a given IP connected to the network and that it is reachable at a given IP
address. address. Registration also facilitates low-power operation since a
device can delegate part of the discovery signaling and reachability
The registration part is easy; a resource directory or mirror proxy requirements to another node.
can be used. The device should perform the necessary registration
with these devices, for instance, as specified in
[I-D.ietf-core-resource-directory] and [I-D.vial-core-mirror-proxy]. The registration part is easy e.g., with a resource directory. The
In order to do this registration, the device needs to know its CORE device should perform the necessary registration with these devices,
Link Format description, as specified in [RFC6690]. In essence, the for instance, as specified in [I-D.ietf-core-resource-directory]. In
order to do this registration, the device needs to know its CoRE Link
Format description, as specified in [RFC6690]. In essence, the
registration process involves performing a GET on .well-known/ registration process involves performing a GET on .well-known/
core/?rt=core-rd at the address of the resource directory (or core/?rt=core-rd at the address of the resource directory, and then
rt=core-mp for mirror proxies), and then doing a POST on the path of doing a POST on the path of the discovered resource.
the discovered resource.
However, current CoAP specifications provide limited support for Other mechanisms enabling device discovery and delegation of
discovering the resource directory or mirror proxy. Local multicast functionality to a non-sleepy node include
discovery only works in LAN-type networks, but not in these public [I-D.vial-core-mirror-proxy] and [I-D.koster-core-coapmq].
cellular networks. Our recommended alternate methods for discovery
are the following: However, current CoAP specifications provide only limited support for
discovering the resource directory or other registration services.
Local multicast discovery only works in LAN-type networks, but not in
these public cellular networks. Our recommended alternate methods
for discovery are the following:
Manual Configuration Manual Configuration
The DNS name of the resource directory or mirror proxy is manually The DNS name of the resource directory is manually configured.
configured. This approach is suitable in situations where the This approach is suitable in situations where the owner of the
owner of the devices has the resources and capabilities to do the devices has the resources and capabilities to do the
configuration. For instance, a utility company can typically configuration. For instance, a utility company can typically
program its metering devices to point to the company servers. program its metering devices to point to the company servers.
Manufacturer Server Manufacturer Server
The DNS name of the directory or proxy is hardwired to the The DNS name of the directory or proxy is hardwired to the
software by the manufacturer, and the directory or proxy is software by the manufacturer, and the directory or proxy is
actually run by the manufacturer. This approach is suitable in actually run by the manufacturer. This approach is suitable in
many consumer usage scenarios, where it would be unreasonable to many consumer usage scenarios, where it would be unreasonable to
assume that the consumer runs any specific network services. The assume that the consumer runs any specific network services. The
skipping to change at page 11, line 31 skipping to change at page 11, line 37
are still incurred. are still incurred.
Note that the the VPN approach can not prevent unwanted traffic Note that the the VPN approach can not prevent unwanted traffic
received at the tunnel endpoint address, and may require keep-alive received at the tunnel endpoint address, and may require keep-alive
traffic. Special APNs can solve this issue, but require explicit traffic. Special APNs can solve this issue, but require explicit
arrangement with the service provider. arrangement with the service provider.
8. Sleepy Devices 8. Sleepy Devices
These devices are best modeled as devices that can delegate queries These devices are best modeled as devices that can delegate queries
to some other node. For instance, as mirror proxy clients to some other node. For instance, as mirror proxy
[I-D.vial-core-mirror-proxy]. When the device initializes itself, it [I-D.vial-core-mirror-proxy] or CoAP Publish-Subscribe
makes a registration of itself in a mirror proxy as described above [I-D.koster-core-coapmq] clients. When the device initializes
in Section 5 and then continues to send periodic updates of sensor itself, it makes a registration of itself in a proxy as described
values. above in Section 5 and then continues to send periodic updates of
sensor values.
As a result, the device acts only as a client, not a server, and can As a result, the device acts only as a client, not a server, and can
shut down all communication channels while it is during its sleeping shut down all communication channels while it is during its sleeping
period. The length of the sleeping period depends on power and period. The length of the sleeping period depends on power and
application requirements. Some environmental sensors might use a day application requirements. Some environmental sensors might use a day
or a week as the period, while other devices may use a smaller values or a week as the period, while other devices may use a smaller values
ranging from minutes to hours. ranging from minutes to hours.
Other approaches for delegation include CoAP-options described in Other approaches for delegation include CoAP-options described in
[I-D.castellani-core-alive] [I-D.castellani-core-alive]
skipping to change at page 13, line 24 skipping to change at page 13, line 33
[I-D.castellani-core-alive] [I-D.castellani-core-alive]
[I-D.fossati-core-publish-monitor-options]. However, we point out [I-D.fossati-core-publish-monitor-options]. However, we point out
that in general, security issues in delegation can be solved either that in general, security issues in delegation can be solved either
through reliance on your local network support nodes (which may be through reliance on your local network support nodes (which may be
quite reasonable in many environments) or explicit end-to-end quite reasonable in many environments) or explicit end-to-end
security. Explicit end-to-end security through nodes that are awake security. Explicit end-to-end security through nodes that are awake
at different times means in practice end-to-end data object security. at different times means in practice end-to-end data object security.
We have implemented one such mechanism for sleepy nodes as described We have implemented one such mechanism for sleepy nodes as described
in [I-D.aks-crypto-sensors]. in [I-D.aks-crypto-sensors].
The security considerations relating to CoAP [I-D.ietf-core-coap] and The security considerations relating to CoAP [RFC7252] and the
the relevant link layers should apply. Note that cellular networks relevant link layers should apply. Note that cellular networks
universally employ per-device authentication, integrity protection, universally employ per-device authentication, integrity protection,
and for most of the world, encryption of all their communications. and for most of the world, encryption of all their communications.
Additional protection of transport sessions is possible through Additional protection of transport sessions is possible through
mechanisms described in [I-D.ietf-core-coap] or data objects. mechanisms described in [RFC7252] or data objects.
10. IANA Considerations 10. IANA Considerations
There are no IANA impacts in this memo. There are no IANA impacts in this memo.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012. Format", RFC 6690, August 2012.
[I-D.ietf-core-coap] [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", RFC 7252, June 2014.
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013.
[I-D.ietf-core-observe] [I-D.ietf-core-observe]
Hartke, K., "Observing Resources in CoAP", draft-ietf- Hartke, K., "Observing Resources in CoAP", draft-ietf-
core-observe-14 (work in progress), June 2014. core-observe-14 (work in progress), June 2014.
[I-D.vial-core-mirror-proxy]
Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-
proxy-01 (work in progress), July 2012.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource
Directory", draft-ietf-core-resource-directory-01 (work in Directory", draft-ietf-core-resource-directory-01 (work in
progress), December 2013. progress), December 2013.
[W3C.REC-exi-20110310] [W3C.REC-exi-20110310]
Kamiya, T. and J. Schneider, "Efficient XML Interchange Kamiya, T. and J. Schneider, "Efficient XML Interchange
(EXI) Format 1.0", World Wide Web Consortium (EXI) Format 1.0", World Wide Web Consortium
Recommendation REC-exi-20110310 Recommendation REC-exi-20110310
http://www.w3.org/TR/2011/REC-exi-20110310, March 2011. http://www.w3.org/TR/2011/REC-exi-20110310, March 2011.
[I-D.jennings-senml] [I-D.jennings-senml]
Jennings, C., Shelby, Z., and J. Arkko, "Media Types for Jennings, C., Shelby, Z., and J. Arkko, "Media Types for
Sensor Markup Language (SENML)", draft-jennings-senml-10 Sensor Markup Language (SENML)", draft-jennings-senml-10
(work in progress), October 2012. (work in progress), October 2012.
[I-D.ietf-lwig-terminology] [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014.
Constrained Node Networks", draft-ietf-lwig-terminology-07
(work in progress), February 2014.
11.2. Informative References 11.2. Informative References
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, January Residential IPv6 Internet Service", RFC 6092, January
2011. 2011.
[I-D.arkko-core-sleepy-sensors] [I-D.arkko-core-sleepy-sensors]
Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
skipping to change at page 15, line 14 skipping to change at page 15, line 10
[I-D.castellani-core-alive] [I-D.castellani-core-alive]
Castellani, A. and S. Loreto, "CoAP Alive Message", draft- Castellani, A. and S. Loreto, "CoAP Alive Message", draft-
castellani-core-alive-00 (work in progress), March 2012. castellani-core-alive-00 (work in progress), March 2012.
[I-D.fossati-core-publish-monitor-options] [I-D.fossati-core-publish-monitor-options]
Fossati, T., Giacomin, P., and S. Loreto, "Publish and Fossati, T., Giacomin, P., and S. Loreto, "Publish and
Monitor Options for CoAP", draft-fossati-core-publish- Monitor Options for CoAP", draft-fossati-core-publish-
monitor-options-01 (work in progress), March 2012. monitor-options-01 (work in progress), March 2012.
[I-D.vial-core-mirror-proxy]
Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-
proxy-01 (work in progress), July 2012.
[I-D.koster-core-coapmq]
Koster, M., Keranen, A., and J. Jimenez, "Message Queueing
in the Constrained Application Protocol (CoAP)", draft-
koster-core-coapmq-00 (work in progress), July 2014.
[Android-Bundle] [Android-Bundle]
"Optimizing Downloads for Efficient Network Access", "Optimizing Downloads for Efficient Network Access",
Android developer note Android developer note
http://developer.android.com/training/efficient-downloads/ http://developer.android.com/training/efficient-downloads/
efficient-network-access.html, February 2013. efficient-network-access.html, February 2013.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Zach Shelby, Jan Holler, Salvatore The authors would like to thank Zach Shelby, Jan Holler, Salvatore
Loreto, Matthew Vial, Thomas Fossati, Mohit Sethi, Jan Melen, Joachim Loreto, Matthew Vial, Thomas Fossati, Mohit Sethi, Jan Melen, Joachim
 End of changes. 18 change blocks. 
60 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/