draft-ietf-lwig-cellular-05.txt   draft-ietf-lwig-cellular-06.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 28, 2016 Ericsson Expires: July 7, 2016 Ericsson
August 27, 2015 January 4, 2016
Building Power-Efficient CoAP Devices for Cellular Networks Building Power-Efficient CoAP Devices for Cellular Networks
draft-ietf-lwig-cellular-05 draft-ietf-lwig-cellular-06
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 28, 2016. This Internet-Draft will expire on July 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 46 skipping to change at page 2, line 46
However, while many of these advantages are obvious and easily However, while many of these advantages are obvious and easily
obtained, optimizing power consumption remains challenging and obtained, optimizing power consumption remains challenging 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 for
the devices in the network.
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
on devices that employ CoAP. As a general technology, CoAP is on devices that employ CoAP. As a general technology, CoAP is
similar to HTTP. It can be used in various ways and network entities similar to HTTP. It can be used in various ways and network entities
may take on different roles. This freedom allows the technology to may take on different roles. This freedom allows the technology to
be used in efficient and less efficient ways. Some guidance is be used in efficient and less efficient ways. Some guidance is
needed to understand what communication models over CoAP are needed to understand what communication models over CoAP are
recommended when low power usage is a critical goal. recommended when low power usage is a critical goal.
The recommendations in this memo should be taken as complementary to The recommendations in this memo should be taken as complementary to
skipping to change at page 4, line 24 skipping to change at page 4, line 25
critical. Cost and practical limits dictate that devices can be critical. Cost and practical limits dictate that devices can be
largely just bought and left on their own. For instance, with largely just bought and left on their own. For instance, with
hundred devices, even a ten-year battery lifetime results in a hundred devices, even a ten-year battery lifetime results in a
monthly battery change for one device within the network. This may monthly battery change for one device within the network. This may
be impractical in many environments. In addition, some devices may be impractical in many environments. In addition, some devices may
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
+----------------+------------------+-----------------+
POWER SOURCE | Seconds | Minutes or Hours | Days and longer |
+------------+----------------+------------------+-----------------+
| | | | |
| Battery | Low-power | Low-power or | Normally-off |
| | | Normally-off | |
+------------+----------------+------------------+-----------------+
| | | | |
| Harvesting | Low-power | Low-power or | Normally-off |
| | | Normally-off | |
+------------+----------------+------------------+-----------------+
| | | | |
| Mains | Always-on | Always-on | Always-on |
| | | | |
+------------+----------------+------------------+-----------------+
Figure 1: Power usage strategies for different classes of
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. Using the power usage
different situations for sensor-type devices, using the power usage strategies described in [RFC7228], mains-powered sensor-type devices
strategies described in [RFC7228], is shown in Figure 1. can use the Always-on strategy whereas battery or energy harvesting
Unfortunately, much of our current technology has been built with devices need to adjust behavior based on the communication interval.
different objectives in mind. Networked devices that are "always For intervals in the order of seconds, Low-power strategy is
on", gadgets that require humans to recharge them every couple of appropriate. For intervals ranging from minutes to hours either Low-
days, and protocols that have been optimized to maximize throughput power or Normally-off strategies are suitable. Finally, for
rather than conserve resources. intervals lasting days and longer, Normally-off is usually the best
choice. Unfortunately, much of our current technology has been built
with different objectives in mind. Networked devices that are
"always on", gadgets that require humans to recharge them every
couple of days, and protocols that have been optimized to maximize
throughput 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 6, line 22 skipping to change at page 6, line 7
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-
specific network configurations or discovery support. For specific network configurations or discovery support. For
instance, the public network helps devices to get on the Internet, instance, the public network helps devices to get on the Internet,
set up default routers, configure DNS servers, and so on, but does set up default routers, configure DNS servers, and so on, but does
nothing for configuring possible higher-layer functions, such as nothing for configuring possible higher-layer functions, such as
servers the device might need to contact to perform its servers the device might need to contact to perform its
application functions. application functions.
Public networks often provide web proxies, and these can in some Public networks often provide web proxies and other functionality
cases make a significant improvement for delays and cost of that can in some cases make a significant improvement for delays
communication over the wireless link. For instance, collecting and cost of communication over the wireless link. For instance,
content from a large number of servers used to render a web page resolving server DNS names in a proxy instead of the user's device
and resolving their DNS names in a proxy instead of the user's may cut down on the general chattiness of the communications,
device may cut down on the general chattiness of the therefore reducing overall delay in completing the entire
communications, therefore reducing overall delay in completing the transaction. Likewise, a CoAP proxy or pub/sub broker
entire transaction. However, as of today such proxies are [I-D.koster-core-coap-pubsub] can assist a CoAP device in
provided only for HTTP communications, not for CoAP. communication. However, unlike HTTP web proxies, CoAP proxies and
brokers are not yet widely deployed in public networks.
Similarly, given the lack of available IPv4 addresses, the chances Similarly, given the lack of available IPv4 addresses, the chances
are that many devices are behind a network address translation are that many devices are behind a network address translation
(NAT) device. This means that they are not easily reachable as (NAT) device. This means that they are not easily reachable as
servers. Alternatively, the devices may be directly on the global servers. Alternatively, the devices may be directly on the global
Internet (either on IPv4 or IPv6) and easily reachable as servers. Internet (either on IPv4 or IPv6) and easily reachable as servers.
Unfortunately, this may mean that they also receive unwanted Unfortunately, this may mean that they also receive unwanted
traffic, which may have implications for both power consumption traffic, which may have implications for both power consumption
and service costs. and service costs.
skipping to change at page 7, line 21 skipping to change at page 7, line 7
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
bigger contributor to energy consumption than message bigger contributor to energy consumption than message
transmission. transmission.
Note that for situations where there are several applications on Note that for situations where there are several applications on
the same device wishing to communicate with the Internet in some the same device wishing to communicate with the Internet in some
manner, bundling those applications together at the same time can manner, bundling those applications together so that they can
be very useful. Some guidance for these techniques in the communicate at the same time can be very useful. Some guidance
smartphone context can be found in [Android-Bundle]. for these techniques in the smartphone context can be found in
[Android-Bundle].
Naturally, each device has a freedom to decide when it sends Naturally, each device has a freedom to decide when it sends
messages. In addition, we assume that there is some way for the messages. In addition, we assume that there is some way for the
devices to control when or how often it wants to receive messages. devices to control when or how often it wants to receive messages.
Specific methods for doing this depend on the specific network being Specific methods for doing this depend on the specific network being
used and also tend to change as improvements in the design of these used and also tend to change as improvements in the design of these
networks are incorporated. The reception control methods generally networks are incorporated. The reception control methods generally
come in two variants, fine grained mechanisms that deal with how come in two variants, fine grained mechanisms that deal with how
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. Furthermore, devices could use Delay-Tolerant
Networking (DTN) [RFC4838] mechanisms to relax the requirements for
timeliness of connectivity and message delivery.
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 at cellular networks: 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
skipping to change at page 10, line 17 skipping to change at page 10, line 5
Common Global Resolution Infrastructure Common Global Resolution Infrastructure
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.)
Besides manual configuration, these alternate mechanisms are mostly
suitable for large manufacturers and deployments. Good automated
mechanism for discovery of devices that are manufactured and deployed
in small quantities are still needed.
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) [RFC7159], 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-core-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
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 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 [RFC7641] may be
[I-D.ietf-core-observe] may be supported. This allows the sensor to supported. This allows the sensor to track changes to the sensed
track changes to the sensed value, and make an immediate observation value, and make an immediate observation response upon a change.
response upon a change. This may reduce the amount of polling needed This may reduce the amount of polling needed to be done by the
to be done by the client. Unfortunately, it does not reduce the time client. Unfortunately, it does not reduce the time that the device
that the device needs to be listening for requests. Subscription needs to be listening for requests. Subscription requests from other
requests from other clients than the currently registered one may clients than the currently registered one may come at any time, the
come at any time, the current client may change its request, and the current client may change its request, and the device still needs to
device still needs to respond to normal queries as a server. As a respond to normal queries as a server. As a result, the sensor can
result, the sensor can not rely having to communicate only on its own not rely having to communicate only on its own choice of observation
choice of observation interval. 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 APN for the private network. Corporate access via cellular a special APN for the private network. Corporate access via cellular
networks has often been arranged in this manner, for instance. networks has often been arranged in this manner, for instance.
Another approach is to use Virtual Private Networking (VPN) Another approach is to use Virtual Private Networking (VPN)
skipping to change at page 13, line 31 skipping to change at page 13, line 20
obvious security issues which have largely NOT yet been addressed in obvious security issues which have largely NOT yet been addressed in
the relevant Internet Drafts [I-D.vial-core-mirror-proxy] the relevant Internet Drafts [I-D.vial-core-mirror-proxy]
[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-lwig-crypto-sensors].
The security considerations relating to CoAP [RFC7252] and the The security considerations relating to CoAP [RFC7252] and 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 [RFC7252] or data objects. mechanisms described in [RFC7252] or data objects.
10. IANA Considerations 10. IANA Considerations
skipping to change at page 14, line 14 skipping to change at page 14, line 5
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>. <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, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <http://www.rfc-editor.org/info/rfc7252>.
[I-D.ietf-core-observe] [RFC7641] Hartke, K., "Observing Resources in the Constrained
Hartke, K., "Observing Resources in CoAP", draft-ietf- Application Protocol (CoAP)", RFC 7641,
core-observe-16 (work in progress), December 2014. DOI 10.17487/RFC7641, September 2015,
<http://www.rfc-editor.org/info/rfc7641>.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
Resource Directory", draft-ietf-core-resource-directory-04 Resource Directory", draft-ietf-core-resource-directory-05
(work in progress), July 2015. (work in progress), October 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- Recommendation REC-
exi-20110310 http://www.w3.org/TR/2011/REC-exi-20110310, exi-20110310 http://www.w3.org/TR/2011/REC-exi-20110310,
March 2011. March 2011.
[I-D.jennings-senml] [I-D.jennings-core-senml]
Jennings, C., Shelby, Z., and J. Arkko, "Media Types for Jennings, C., Shelby, Z., Arkko, J., and A. Keranen,
Sensor Markup Language (SENML)", draft-jennings-senml-10 "Media Types for Sensor Markup Language (SENML)", draft-
(work in progress), October 2012. jennings-core-senml-02 (work in progress), October 2015.
[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, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>. <http://www.rfc-editor.org/info/rfc7228>.
11.2. Informative References 11.2. Informative References
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <http://www.rfc-editor.org/info/rfc4838>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
Capabilities in Customer Premises Equipment (CPE) for Capabilities in Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service", RFC 6092, Providing Residential IPv6 Internet Service", RFC 6092,
DOI 10.17487/RFC6092, January 2011, DOI 10.17487/RFC6092, January 2011,
<http://www.rfc-editor.org/info/rfc6092>. <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-lwig-crypto-sensors]
Sethi, M., Arkko, J., Keranen, A., and H. Rissanen, Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical
"Practical Considerations and Implementation Experiences Considerations and Implementation Experiences in Securing
in Securing Smart Object Networks", draft-aks-crypto- Smart Object Networks", draft-aks-lwig-crypto-sensors-00
sensors-02 (work in progress), March 2012. (work in progress), October 2015.
[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] [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-coap-pubsub] [I-D.koster-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-koster-core-coap-pubsub-02 (work in (CoAP)", draft-koster-core-coap-pubsub-04 (work in
progress), July 2015. progress), November 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. 21 change blocks. 
78 lines changed or deleted 78 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/