draft-ietf-lwig-cellular-04.txt   draft-ietf-lwig-cellular-05.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: November 1, 2015 Ericsson Expires: February 28, 2016 Ericsson
April 30, 2015 August 27, 2015
Building Power-Efficient CoAP Devices for Cellular Networks Building Power-Efficient CoAP Devices for Cellular Networks
draft-ietf-lwig-cellular-04 draft-ietf-lwig-cellular-05
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 November 1, 2015. This Internet-Draft will expire on February 28, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 6, line 4 skipping to change at page 6, line 4
In the following we look at some of these characteristics and their In the following we look at some of these characteristics and their
implications. Note that in most cases these characteristics are not implications. Note that in most cases these characteristics are not
properties of the specific networks but rather inherent in the properties of the specific networks but rather inherent in the
concept of public networks. concept of public networks.
Public networks Public networks
Using a public network service implies that applications can be Using a public network service implies that applications can be
deployed without having to build a network to go with them. For deployed without having to build a network to go with them. For
economical reasons, only the largest users (such as utility economic reasons, only the largest users (such as utility
companies) could afford to build their own network, and even they companies) could afford to build their own network, and even they
would not be able to provide a world-wide coverage. This means would not be able to provide a world-wide coverage. This means
that applications where coverage is important can be built. For that applications where coverage is important can be built. For
instance, most transport sector applications require national or instance, most transport sector applications require national or
even world-wide coverage to work. even world-wide coverage to work.
But there are other implications, as well. By definition, the But there are other implications, as well. By definition, the
network is not tailored for this application and with some network is not tailored for this application and with some
exceptions, the traffic passes through the Internet. One exceptions, the traffic passes through the Internet. One
implication of this is that there are generally no application- implication of this is that there are generally no application-
skipping to change at page 9, line 16 skipping to change at page 9, line 16
device should perform the necessary registration with these devices, device should perform the necessary registration with these devices,
for instance, as specified in [I-D.ietf-core-resource-directory]. In 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 order to do this registration, the device needs to know its CoRE Link
Format description, as specified in [RFC6690]. In essence, the 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, and then core/?rt=core-rd at the address of the resource directory, and then
doing a POST on the path of the discovered resource. doing a POST on the path of the discovered resource.
Other mechanisms enabling device discovery and delegation of Other mechanisms enabling device discovery and delegation of
functionality to a non-sleepy node include functionality to a non-sleepy node include
[I-D.vial-core-mirror-proxy] and [I-D.koster-core-coapmq]. [I-D.vial-core-mirror-proxy] and [I-D.koster-core-coap-pubsub].
However, current CoAP specifications provide only limited support for However, current CoAP specifications provide only limited support for
discovering the resource directory or other registration services. discovering the resource directory or other registration services.
Local multicast discovery only works in LAN-type networks, but not in Local multicast discovery only works in LAN-type networks, but not in
these public cellular networks. Our recommended alternate methods these public cellular networks. Our recommended alternate methods
for discovery are the following: for discovery are the following:
Manual Configuration Manual Configuration
The DNS name of the resource directory is manually configured. The DNS name of the resource directory is manually configured.
skipping to change at page 10, line 20 skipping to change at page 10, line 20
The delegating manufacturer server model could be generalized into The delegating manufacturer server model could be generalized into
a reverse-DNS -like discovery infrastructure that could answer the a reverse-DNS -like discovery infrastructure that could answer the
question "this is device with identity ID, where is my home question "this is device with identity ID, where is my home
registration server?". However, at present no such resolution registration server?". However, at present no such resolution
system exists. (Note: The EPCGlobal system for RFID resolution is system exists. (Note: The EPCGlobal system for RFID resolution is
reminiscent of this approach.) reminiscent of this approach.)
6. Data Formats 6. Data Formats
A variety of data formats exist for passing around data. These data A variety of data formats exist for passing around data. These data
formats include XML, JavaScript Object Notation (JSON) [RFC4627], formats include XML, JavaScript Object Notation (JSON) [RFC7159],
Efficient XML Interchange (EXI) [W3C.REC-exi-20110310], and text Efficient XML Interchange (EXI) [W3C.REC-exi-20110310], and text
formats. Message lengths can have a significant effect on the amount formats. Message lengths can have a significant effect on the amount
of energy required for the communications, and such it is highly of energy required for the communications, and such it is highly
desirable to keep message lengths minimal. At the same time, extreme desirable to keep message lengths minimal. At the same time, extreme
optimization can affect flexibility and ease of programming. The optimization can affect flexibility and ease of programming. The
authors recommend [I-D.jennings-senml] as a compact, yet easily authors recommend [I-D.jennings-senml] as a compact, yet easily
processed and extendable textual format. processed and extendable textual format.
7. Real-Time Reachable Devices 7. Real-Time Reachable Devices
skipping to change at page 11, line 39 skipping to change at page 11, line 39
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 to some other node. For instance, as mirror proxy
[I-D.vial-core-mirror-proxy] or CoAP Publish-Subscribe [I-D.vial-core-mirror-proxy] or CoAP Publish-Subscribe
[I-D.koster-core-coapmq] clients. When the device initializes [I-D.koster-core-coap-pubsub] clients. When the device initializes
itself, it makes a registration of itself in a proxy as described itself, it makes a registration of itself in a proxy as described
above in Section 5 and then continues to send periodic updates of above in Section 5 and then continues to send periodic updates of
sensor values. 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.
skipping to change at page 13, line 48 skipping to change at page 13, line 48
mechanisms described in [RFC7252] 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 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
JavaScript Object Notation (JSON)", RFC 4627, July 2006. Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012. Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014. Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[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-16 (work in progress), December 2014. core-observe-16 (work in progress), December 2014.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z. and C. Bormann, "CoRE Resource Directory", Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
draft-ietf-core-resource-directory-02 (work in progress), Resource Directory", draft-ietf-core-resource-directory-04
November 2014. (work in progress), July 2015.
[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-
http://www.w3.org/TR/2011/REC-exi-20110310, March 2011. exi-20110310 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.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014. Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
11.2. Informative References 11.2. Informative References
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
Customer Premises Equipment (CPE) for Providing Capabilities in Customer Premises Equipment (CPE) for
Residential IPv6 Internet Service", RFC 6092, January Providing Residential IPv6 Internet Service", RFC 6092,
2011. DOI 10.17487/RFC6092, January 2011,
<http://www.rfc-editor.org/info/rfc6092>.
[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.
Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- Novo, "Implementing Tiny COAP Sensors", draft-arkko-core-
sleepy-sensors-01 (work in progress), July 2011. sleepy-sensors-01 (work in progress), July 2011.
[I-D.aks-crypto-sensors] [I-D.aks-crypto-sensors]
Sethi, M., Arkko, J., Keranen, A., and H. Rissanen, Sethi, M., Arkko, J., Keranen, A., and H. Rissanen,
"Practical Considerations and Implementation Experiences "Practical Considerations and Implementation Experiences
in Securing Smart Object Networks", draft-aks-crypto- in Securing Smart Object Networks", draft-aks-crypto-
skipping to change at page 15, line 14 skipping to change at page 15, line 24
[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] [I-D.vial-core-mirror-proxy]
Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-
proxy-01 (work in progress), July 2012. proxy-01 (work in progress), July 2012.
[I-D.koster-core-coapmq] [I-D.koster-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Message Queueing Koster, M., Keranen, A., and J. Jimenez, "Publish-
in the Constrained Application Protocol (CoAP)", draft- Subscribe Broker for the Constrained Application Protocol
koster-core-coapmq-00 (work in progress), July 2014. (CoAP)", draft-koster-core-coap-pubsub-02 (work in
progress), July 2015.
[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
 End of changes. 15 change blocks. 
26 lines changed or deleted 35 lines changed or added

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