draft-ietf-lwig-cellular-00.txt   draft-ietf-lwig-cellular-01.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 15, 2014 Ericsson Expires: August 17, 2014 Ericsson
August 14, 2013 February 13, 2014
Building Power-Efficient CoAP Devices for Cellular Networks Building Power-Efficient CoAP Devices for Cellular Networks
draft-ietf-lwig-cellular-00 draft-ietf-lwig-cellular-01
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 15, 2014. This Internet-Draft will expire on August 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 29 skipping to change at page 4, line 29
be physically difficult to reach for a battery change. Or, a large be physically difficult to reach for a battery change. Or, a large
group of devices -- such as utility meters or environmental sensors group of devices -- such as utility meters or environmental sensors
-- cannot be economically serviced too often, even if in theory the -- cannot be economically serviced too often, even if in theory the
batteries could be changed. batteries could be changed.
SENSOR COMMUNICATION INTERVAL SENSOR COMMUNICATION INTERVAL
+----------------+------------------+-----------------+ +----------------+------------------+-----------------+
POWER SOURCE | Seconds | Minutes or Hours | Days and longer | POWER SOURCE | Seconds | Minutes or Hours | Days and longer |
+------------+----------------+------------------+-----------------+ +------------+----------------+------------------+-----------------+
| | | | | | | | | |
| Battery | Low-power | Low-power or | Always-off | | Battery | Low-power | Low-power or | Normally-off |
| | | Always-off | | | | | Normally-off | |
+------------+----------------+------------------+-----------------+ +------------+----------------+------------------+-----------------+
| | | | | | | | | |
| Harvesting | Low-power | Low-power or | Always-off | | Harvesting | Low-power | Low-power or | Normally-off |
| | | Always-off | | | | | Normally-off | |
+------------+----------------+------------------+-----------------+ +------------+----------------+------------------+-----------------+
| | | | | | | | | |
| 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
skipping to change at page 6, line 50 skipping to change at page 6, line 50
Point-to-point link model Point-to-point link model
This is a common link model in cellular networks. One implication This is a common link model in cellular networks. One implication
of this model is that there will be no other nodes on the same of this model is that there will be no other nodes on the same
link, except maybe for the service provider's router. As a link, except maybe for the service provider's router. As a
result, multicast discovery can not be reasonably used for any result, multicast discovery can not be reasonably used for any
local discovery purposes. While the configuration of the service local discovery purposes. While the configuration of the service
provider's router for specific users is theoretically possible, in provider's router for specific users is theoretically possible, in
practice this is difficult to achieve, at least for any small user practice this is difficult to achieve, at least for any small user
that can not afford a network-wide contract for a private APN. that can not afford a network-wide contract for a private APN
The public network access service has little per-user tailoring. (Access Point Name). The public network access service has little
per-user tailoring.
Radio technology Radio technology
The use of radio technology means that power is needed to operate The use of radio technology means that power is needed to operate
the radios. Transmission generally requires more power than the radios. Transmission generally requires more power than
reception. However, radio protocols have generally been designed reception. However, radio protocols have generally been designed
so that a device checks periodically whether it has messages. In so that a device checks periodically whether it has messages. In
a situation where messages arrive seldom or not at all, this a situation where messages arrive seldom or not at all, this
checking consumes energy. Research has shown that these periodic checking consumes energy. Research has shown that these periodic
checks (such as LTE paging message reception) are often a far checks (such as LTE paging message reception) are often a far
skipping to change at page 8, line 50 skipping to change at page 9, line 4
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.
The registration part is easy; a resource directory or mirror proxy The registration part is easy; a resource directory or mirror proxy
can be used. The device should perform the necessary registration can be used. The device should perform the necessary registration
with these devices, for instance, as specified in with these devices, for instance, as specified in
[I-D.shelby-core-resource-directory] and
[I-D.vial-core-mirror-proxy]. In order to do this registration, the [I-D.ietf-core-resource-directory] and [I-D.vial-core-mirror-proxy].
device needs to know its CORE Link Format description, as specified In order to do this registration, the device needs to know its CORE
in [RFC6690]. In essence, the registration process involves Link Format description, as specified in [RFC6690]. In essence, the
performing a GET on .well-known/core/?rt=core-rd at the address of registration process involves performing a GET on .well-known/core/
the resource directory (or rt=core-mp for mirror proxies), and then ?rt=core-rd at the address of the resource directory (or rt=core-mp
doing a POST on the path of the discovered resource. for mirror proxies), and then doing a POST on the path of the
discovered resource.
However, current CoAP specifications provide limited support for However, current CoAP specifications provide limited support for
discovering the resource directory or mirror proxy. Local multicast discovering the resource directory or mirror proxy. Local multicast
discovery only works in LAN-type networks, but not in these public discovery only works in LAN-type networks, but not in these public
cellular networks. Our recommended alternate methods for discovery cellular networks. Our recommended alternate methods for discovery
are the following: 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 or mirror proxy is manually
skipping to change at page 10, line 12 skipping to change at page 10, line 14
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, JSON, EXI, and text formats. Message lengths formats include XML, JavaScript Object Notation (JSON) [RFC4627],
can have a significant effect on the amount of energy required for Efficient XML Interchange (EXI) [W3C.REC-exi-20110310], and text
the communications, and such it is highly desirable to keep message formats. Message lengths can have a significant effect on the amount
lengths minimal. At the same time, extreme optimization can affect of energy required for the communications, and such it is highly
flexibility and ease of programming. The authors recommend desirable to keep message lengths minimal. At the same time, extreme
[I-D.jennings-senml] as a compact, yet easily processed and optimization can affect flexibility and ease of programming. The
extendable textual format. authors recommend [I-D.jennings-senml] as a compact, yet easily
processed and extendable textual format.
7. Real-Time Reachable Devices 7. Real-Time Reachable Devices
These devices are often best modeled as CoAP servers. The device These devices are often best modeled as CoAP servers. The device
will have limited control on when it receives messages, and it will will have limited control on when it receives messages, and it will
have to listen actively for messages, up to the limits of the have to listen actively for messages, up to the limits of the
underlying link layer. If the device acts also in client role in underlying link layer. If the device acts also in client role in
some phase of its operation, it can control how many transmissions it some phase of its operation, it can control how many transmissions it
makes on its own behalf. makes on its own behalf.
The packet reception checks should be tailored according to the The packet reception checks should be tailored according to the
requirements of the application. If sub-second response time is not requirements of the application. If sub-second response time is not
needed, a slightly more infrequent checking process may save some needed, a slightly more infrequent checking process may save some
power. power.
For sensor-type devices, the CoAP OBSERVE extension For sensor-type devices, the CoAP Observe extension
[I-D.ietf-core-observe] may be supported. This allows the sensor to [I-D.ietf-core-observe] may be supported. This allows the sensor to
track changes to the sensed value, and make an immediate observation track changes to the sensed value, and make an immediate observation
response upon a change. This may reduce the amount of polling needed response upon a change. This may reduce the amount of polling needed
to be done by the client. Unfortunately, it does not reduce the time to be done by the client. Unfortunately, it does not reduce the time
that the device needs to be listening for requests. Subscription that the device needs to be listening for requests. Subscription
requests from other clients than the currently registered one may requests from other clients than the currently registered one may
come at any time, the current client may change its request, and the come at any time, the current client may change its request, and the
device still needs to respond to normal queries as a server. As a device still needs to respond to normal queries as a server. As a
result, the sensor can not rely having to communicate only on its own result, the sensor can not rely having to communicate only on its own
choice of observation interval. choice of observation interval.
In order to act as a server, the device needs to be placed in a In order to act as a server, the device needs to be placed in a
public IPv4 address, be reachable over IPv6, or hosted in a private public IPv4 address, be reachable over IPv6, or hosted in a private
network. If the the device is hosted on a private network, then all network. If the the device is hosted on a private network, then all
other nodes need to access this device also need to reside in the other nodes need to access this device also need to reside in the
same private network. There are multiple ways to provide private same private network. There are multiple ways to provide private
networks over public cellular networks. One approach is to dedicate networks over public cellular networks. One approach is to dedicate
a special Access Point Name or APN for the private network. a special APN for the private network. Corporate access via cellular
Corporate access via cellular networks has often been arranged in networks has often been arranged in this manner, for instance.
this manner, for instance. Another approach is to use Virtual Another approach is to use Virtual Private Networking (VPN)
Private Networking (VPN) technology, for instance IPsec-based VPNs. technology, for instance IPsec-based VPNs.
Power consumption from unwanted traffic is problematic in these Power consumption from unwanted traffic is problematic in these
devices, unless placed in a private network or protected by a devices, unless placed in a private network or protected by a
operator-provided firewall service. Devices on an IPv6 network will operator-provided firewall service. Devices on an IPv6 network will
have some protection through the nature of the 2^64 address have some protection through the nature of the 2^64 address
allocation for a single terminal in a 3GPP cellular network; the allocation for a single terminal in a 3GPP cellular network; the
attackers will be unable to guess the full IP address of the device. attackers will be unable to guess the full IP address of the device.
However, this protects only the device from processing a packet, but However, this protects only the device from processing a packet, but
since the network will still deliver the packet to any of the since the network will still deliver the packet to any of the
addresses within the assigned 64-bit prefix, packet reception costs addresses within the assigned 64-bit prefix, packet reception costs
skipping to change at page 13, line 37 skipping to change at page 13, line 39
mechanisms described in [I-D.ietf-core-coap] or data objects. mechanisms described in [I-D.ietf-core-coap] 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
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] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18 Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013. (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-09 (work in progress), July 2013. core-observe-11 (work in progress), October 2013.
[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.shelby-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource
Directory", draft-shelby-core-resource-directory-05 (work Directory", draft-ietf-core-resource-directory-01 (work in
in progress), February 2013. progress), December 2013.
[W3C.REC-exi-20110310]
Kamiya, T. and J. Schneider, "Efficient XML Interchange
(EXI) Format 1.0", World Wide Web Consortium
Recommendation REC-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.
[I-D.ietf-lwig-terminology] [I-D.ietf-lwig-terminology]
Bormann, C., Ersue, M., and A. Keranen, "Terminology for Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained Node Networks", draft-ietf-lwig-terminology-05 Constrained Node Networks", draft-ietf-lwig-terminology-07
(work in progress), July 2013. (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 14, line 48 skipping to change at page 15, line 15
[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.
[Android-Bundle] [Android-Bundle]
, "Optimizing Downloads for Efficient Network Access", "Optimizing Downloads for Efficient Network Access",
Android developer note http://developer.android.com/ Android developer note http://developer.android.com/
training/efficient-downloads/efficient-network- training/efficient-downloads/
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
Sachs, Heidi-Maria Rissanen, Sebastien Pierrel, Kumar Balachandran, Sachs, Heidi-Maria Rissanen, Sebastien Pierrel, Kumar Balachandran,
Muhammad Waqas Mir, Cullen Jennings, Markus Isomaki, Hannes Muhammad Waqas Mir, Cullen Jennings, Markus Isomaki, Hannes
Tschofenig, and Anna Larmo for interesting discussions in this Tschofenig, and Anna Larmo for interesting discussions in this
problem space. problem space.
 End of changes. 17 change blocks. 
40 lines changed or deleted 52 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/