draft-ietf-lpwan-overview-06.txt   draft-ietf-lpwan-overview-07.txt 
lpwan S. Farrell, Ed. lpwan S. Farrell, Ed.
Internet-Draft Trinity College Dublin Internet-Draft Trinity College Dublin
Intended status: Informational July 21, 2017 Intended status: Informational October 3, 2017
Expires: January 22, 2018 Expires: April 6, 2018
LPWAN Overview LPWAN Overview
draft-ietf-lpwan-overview-06 draft-ietf-lpwan-overview-07
Abstract Abstract
Low Power Wide Area Networks (LPWAN) are wireless technologies with Low Power Wide Area Networks (LPWAN) are wireless technologies with
characteristics such as large coverage areas, low bandwidth, possibly characteristics such as large coverage areas, low bandwidth, possibly
very small packet and application layer data sizes and long battery very small packet and application layer data sizes and long battery
life operation. This memo is an informational overview of the set of life operation. This memo is an informational overview of the set of
LPWAN technologies being considered in the IETF and of the gaps that LPWAN technologies being considered in the IETF and of the gaps that
exist between the needs of those technologies and the goal of running exist between the needs of those technologies and the goal of running
IP in LPWANs. IP in LPWANs.
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 January 22, 2018. This Internet-Draft will expire on April 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 4, line 11 skipping to change at page 4, line 11
Note that some of the technology-specific drafts referenced below may Note that some of the technology-specific drafts referenced below may
have been updated since publication of this document. have been updated since publication of this document.
2.1. LoRaWAN 2.1. LoRaWAN
Text here is largely from [I-D.farrell-lpwan-lora-overview] Text here is largely from [I-D.farrell-lpwan-lora-overview]
2.1.1. Provenance and Documents 2.1.1. Provenance and Documents
LoRaWAN is a wireless technology for long-range low-power low-data- LoRaWAN is an ISM-based wireless technology for long-range low-power
rate applications developed by the LoRa Alliance, a membership low-data-rate applications developed by the LoRa Alliance, a
consortium. <https://www.lora-alliance.org/> This draft is based on membership consortium. <https://www.lora-alliance.org/> This draft
version 1.0.2 [LoRaSpec] of the LoRa specification. Version 1.0, is based on version 1.0.2 [LoRaSpec] of the LoRa specification. That
which has also seen some deployment, is available at [LoRaSpec1.0]. specification is publicly available and has already seen several
deployments across the globe.
2.1.2. Characteristics 2.1.2. Characteristics
LoRaWAN aims to support end-devices operating on a single battery for
an extended period of time (e.g., 10 years or more), extended
coverage through 155 dB maximum coupling loss, and reliable and
efficient file download (as needed for remote software/firmware
upgrade).
LoRaWAN networks are typically organized in a star-of-stars topology LoRaWAN networks are typically organized in a star-of-stars topology
in which gateways relay messages between end-devices and a central in which gateways relay messages between end-devices and a central
"network server" in the backend. Gateways are connected to the "network server" in the backend. Gateways are connected to the
network server via IP links while end-devices use single-hop LoRaWAN network server via IP links while end-devices use single-hop LoRaWAN
communication that can be received at one or more gateways. communication that can be received at one or more gateways.
Communication is generally bi-directional; uplink communication from Communication is generally bi-directional; uplink communication from
end-devices to the network server is favored in terms of overall end-devices to the network server is favored in terms of overall
bandwidth availability. bandwidth availability.
Figure 1 shows the entities involved in a LoRaWAN network. Figure 1 shows the entities involved in a LoRaWAN network.
skipping to change at page 8, line 39 skipping to change at page 8, line 39
have all of the above, plus channel information, somehow have all of the above, plus channel information, somehow
(pre-)provisioned, in which case the end-device can simply start (pre-)provisioned, in which case the end-device can simply start
transmitting. This is achievable in many cases via out-of-band means transmitting. This is achievable in many cases via out-of-band means
given the nature of LoRaWAN networks. Table 3 summarizes these given the nature of LoRaWAN networks. Table 3 summarizes these
values. values.
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| Value | Description | | Value | Description |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| DevAddr | DevAddr (32-bits) = device-specific network address | | DevAddr | DevAddr (32-bits) = device-specific network address |
| | generated from the NwkID | | | generated from the NetID |
| | | | | |
| AppEUI | IEEE EUI64 corresponding to the join server for an | | AppEUI | IEEE EUI64 corresponding to the join server for an |
| | application | | | application |
| | | | | |
| NwkSKey | 128-bit network session key used with AES-CMAC | | NwkSKey | 128-bit network session key used with AES-CMAC |
| | | | | |
| AppSKey | 128-bit application session key used with AES-CTR | | AppSKey | 128-bit application session key used with AES-CTR |
| | | | | |
| AppKey | 128-bit application session key used with AES-ECB | | AppKey | 128-bit application session key used with AES-ECB |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
skipping to change at page 13, line 14 skipping to change at page 13, line 14
the mobility of the UE. MME tasks include tracking and paging UEs, the mobility of the UE. MME tasks include tracking and paging UEs,
session management, choosing the Serving gateway for the UE during session management, choosing the Serving gateway for the UE during
initial attachment and authenticating the user. At MME, the Non- initial attachment and authenticating the user. At MME, the Non-
Access Stratum (NAS) signaling from the UE is terminated. Access Stratum (NAS) signaling from the UE is terminated.
Serving Gateway (S-GW) routes and forwards the user data packets Serving Gateway (S-GW) routes and forwards the user data packets
through the access network and acts as a mobility anchor for UEs through the access network and acts as a mobility anchor for UEs
during handover between base stations known as eNodeBs and also during handover between base stations known as eNodeBs and also
during handovers between NB-IoT and other 3GPP technologies. during handovers between NB-IoT and other 3GPP technologies.
Packet Data Node Gateway (P-GW) works as an interface between 3GPP Packet Data Network Gateway (P-GW) works as an interface between 3GPP
network and external networks. network and external networks.
The Home Subscriber Server (HSS) contains user-related and The Home Subscriber Server (HSS) contains user-related and
subscription- related information. It is a database, which performs subscription- related information. It is a database, which performs
mobility management, session establishment support, user mobility management, session establishment support, user
authentication and access authorization. authentication and access authorization.
E-UTRAN consists of components of a single type, eNodeB. eNodeB is a E-UTRAN consists of components of a single type, eNodeB. eNodeB is a
base station, which controls the UEs in one or several cells. base station, which controls the UEs in one or several cells.
The 3GPP radio protocol architecture is illustration in Figure 4. The 3GPP radio protocol architecture is illustrated in Figure 4.
+---------+ +---------+ +---------+ +---------+
| NAS |----|-----------------------------|----| NAS | | NAS |----|-----------------------------|----| NAS |
+---------+ | +---------+---------+ | +---------+ +---------+ | +---------+---------+ | +---------+
| RRC |----|----| RRC | S1-AP |----|----| S1-AP | | RRC |----|----| RRC | S1-AP |----|----| S1-AP |
+---------+ | +---------+---------+ | +---------+ +---------+ | +---------+---------+ | +---------+
| PDCP |----|----| PDCP | SCTP |----|----| SCTP | | PDCP |----|----| PDCP | SCTP |----|----| SCTP |
+---------+ | +---------+---------+ | +---------+ +---------+ | +---------+---------+ | +---------+
| RLC |----|----| RLC | IP |----|----| IP | | RLC |----|----| RLC | IP |----|----| IP |
+---------+ | +---------+---------+ | +---------+ +---------+ | +---------+---------+ | +---------+
skipping to change at page 14, line 4 skipping to change at page 14, line 4
Figure 4: 3GPP radio protocol architecture for control plane Figure 4: 3GPP radio protocol architecture for control plane
Control plane protocol stack Control plane protocol stack
The radio protocol architecture of NB-IoT (and LTE) is separated into The radio protocol architecture of NB-IoT (and LTE) is separated into
control plane and user plane. The control plane consists of control plane and user plane. The control plane consists of
protocols which control the radio access bearers and the connection protocols which control the radio access bearers and the connection
between the UE and the network. The highest layer of control plane between the UE and the network. The highest layer of control plane
is called Non-Access Stratum (NAS), which conveys the radio signaling is called Non-Access Stratum (NAS), which conveys the radio signaling
between the UE and the EPC, passing transparently through the radio between the UE and the Evolved Packet Core (EPC), passing
network. NAS responsible for authentication, security control, transparently through the radio network. NAS responsible for
mobility management and bearer management. authentication, security control, mobility management and bearer
management.
Access Stratum (AS) is the functional layer below NAS, and in the Access Stratum (AS) is the functional layer below NAS, and in the
control plane it consists of Radio Resource Control protocol (RRC) control plane it consists of Radio Resource Control protocol (RRC)
[TGPP36331], which handles connection establishment and release [TGPP36331], which handles connection establishment and release
functions, broadcast of system information, radio bearer functions, broadcast of system information, radio bearer
establishment, reconfiguration and release. RRC configures the user establishment, reconfiguration and release. RRC configures the user
and control planes according to the network status. There exists two and control planes according to the network status. There exists two
RRC states, RRC_Idle or RRC_Connected, and RRC entity controls the RRC states, RRC_Idle or RRC_Connected, and RRC entity controls the
switching between these states. In RRC_Idle, the network knows that switching between these states. In RRC_Idle, the network knows that
the UE is present in the network and the UE can be reached in case of the UE is present in the network and the UE can be reached in case of
skipping to change at page 28, line 42 skipping to change at page 28, line 42
and duty-cycle-free or equivalent operation), an RS/RA/NS/NA exchange and duty-cycle-free or equivalent operation), an RS/RA/NS/NA exchange
may be completed in a few seconds, without incurring packet may be completed in a few seconds, without incurring packet
fragmentation. fragmentation.
In other LPWANs (with a maximum payload size of ~10 bytes, and a In other LPWANs (with a maximum payload size of ~10 bytes, and a
message rate of ~0.1 message/minute), the same exchange may take message rate of ~0.1 message/minute), the same exchange may take
hours or even days, leading to severe fragmentation and consuming a hours or even days, leading to severe fragmentation and consuming a
significant amount of the available network resources. 6LoWPAN significant amount of the available network resources. 6LoWPAN
Neighbor Discovery behavior may be tuned through the use of Neighbor Discovery behavior may be tuned through the use of
appropriate values for the default Router Lifetime, the Valid appropriate values for the default Router Lifetime, the Valid
Lifetime in the PIOs, and the Valid Lifetime in the 6CO, as well as Lifetime in the PIOs, and the Valid Lifetime in the 6LowPan Context
the address Registration Lifetime. However, for the latter LPWANs Option (6CO), as well as the address Registration Lifetime. However,
mentioned above, 6LoWPAN Neighbor Discovery is not suitable. for the latter LPWANs mentioned above, 6LoWPAN Neighbor Discovery is
not suitable.
4.3. 6lo 4.3. 6lo
The 6lo WG has been reusing and adapting 6LoWPAN to enable IPv6 The 6lo WG has been reusing and adapting 6LoWPAN to enable IPv6
support over link layer technologies such as Bluetooth Low Energy support over link layer technologies such as Bluetooth Low Energy
(BTLE), ITU-T G.9959, DECT-ULE, MS/TP-RS485, NFC IEEE 802.11ah. (See (BTLE), ITU-T G.9959, DECT-ULE, MS/TP-RS485, NFC IEEE 802.11ah. (See
<https://tools.ietf.org/wg/6lo> for details.) These technologies are <https://tools.ietf.org/wg/6lo> for details.) These technologies are
similar in several aspects to IEEE 802.15.4, which was the original similar in several aspects to IEEE 802.15.4, which was the original
6LoWPAN target technology. 6LoWPAN target technology.
skipping to change at page 30, line 35 skipping to change at page 30, line 38
L2 acknowledgments. On the other hand, the current work in progress L2 acknowledgments. On the other hand, the current work in progress
in the CoRE WG where the COMI/CoOL network management interface in the CoRE WG where the COMI/CoOL network management interface
which, uses Structured Identifiers (SID) to reduce payload size over which, uses Structured Identifiers (SID) to reduce payload size over
CoAP may prove to be a good solution for the LPWAN technologies. The CoAP may prove to be a good solution for the LPWAN technologies. The
overhead is reduced by adding a dictionary which matches a URI to a overhead is reduced by adding a dictionary which matches a URI to a
small identifier and a compact mapping of the YANG model into the small identifier and a compact mapping of the YANG model into the
CBOR binary representation. CBOR binary representation.
4.8. Mobility 4.8. Mobility
LPWANs nodes can be mobile. However, LPWAN mobility is different LPWAN nodes can be mobile. However, LPWAN mobility is different from
from the one specified for Mobile IP. LPWAN implies sporadic traffic the one specified for Mobile IP. LPWAN implies sporadic traffic and
and will rarely be used for high-frequency, real-time communications. will rarely be used for high-frequency, real-time communications.
The applications do not generate a flow, they need to save energy and The applications do not generate a flow, they need to save energy and
most of the time the node will be down. most of the time the node will be down.
In addition, LPWAN mobility may mostly apply to groups of devices, In addition, LPWAN mobility may mostly apply to groups of devices,
that represent a network in which case mobility is more a concern for that represent a network in which case mobility is more a concern for
the gateway than the devices. NEMO [RFC3963] Mobility solutions may the gateway than the devices. NEMO [RFC3963] Mobility or other
mobile gateway solutions (such as a gateway with an LTE uplink) may
be used in the case where some end-devices belonging to the same be used in the case where some end-devices belonging to the same
network gateway move from one point to another such that they are not network gateway move from one point to another such that they are not
aware of being mobile. aware of being mobile.
4.9. DNS and LPWAN 4.9. DNS and LPWAN
The Domain Name System (DNS) DNS [RFC1035], enables applications to The Domain Name System (DNS) DNS [RFC1035], enables applications to
name things with a globally resolvable name. Many protocols use the name things with a globally resolvable name. Many protocols use the
DNS to identify hosts, for example applications using CoAP. DNS to identify hosts, for example applications using CoAP.
skipping to change at page 31, line 51 skipping to change at page 31, line 51
more typical network, one would consider defining padding mechanisms more typical network, one would consider defining padding mechanisms
and allowing for cover traffic. In some LPWANs, those mechanisms may and allowing for cover traffic. In some LPWANs, those mechanisms may
not be feasible. Nonetheless, the privacy challenges do exist and not be feasible. Nonetheless, the privacy challenges do exist and
can be real and so some solutions will be needed. Note that many can be real and so some solutions will be needed. Note that many
aspects of solutions in this space may not be visible in IETF aspects of solutions in this space may not be visible in IETF
specifications, but can be e.g. implementation or deployment specifications, but can be e.g. implementation or deployment
specific. specific.
Another challenge for LPWANs will be how to handle key management and Another challenge for LPWANs will be how to handle key management and
associated protocols. In a more traditional network (e.g. the web), associated protocols. In a more traditional network (e.g. the web),
servers can "staple" OCSP responses in order to allow browsers to servers can "staple" Online Certificate Status Protocol (OCSP)
check revocation status for presented certificates. [RFC6961] While responses in order to allow browsers to check revocation status for
the stapling approach is likely something that would help in an presented certificates. [RFC6961] While the stapling approach is
LPWAN, as it avoids an RTT, certificates and OCSP responses are bulky likely something that would help in an LPWAN, as it avoids an RTT,
items and will prove challenging to handle in LPWANs with bounded certificates and OCSP responses are bulky items and will prove
bandwidth. challenging to handle in LPWANs with bounded bandwidth.
6. IANA Considerations 6. IANA Considerations
There are no IANA considerations related to this memo. There are no IANA considerations related to this memo.
7. Contributors 7. Contributors
As stated above this document is mainly a collection of content As stated above this document is mainly a collection of content
developed by the full set of contributors listed below. The main developed by the full set of contributors listed below. The main
input documents and their authors were: input documents and their authors were:
skipping to change at page 35, line 19 skipping to change at page 35, line 19
Alexander Pelov and Pascal Thubert were the LPWAN WG chairs while Alexander Pelov and Pascal Thubert were the LPWAN WG chairs while
this document was developed. this document was developed.
Stephen Farrell's work on this memo was supported by Pervasive Stephen Farrell's work on this memo was supported by Pervasive
Nation, the Science Foundation Ireland's CONNECT centre national IoT Nation, the Science Foundation Ireland's CONNECT centre national IoT
network. <https://connectcentre.ie/pervasive-nation/> network. <https://connectcentre.ie/pervasive-nation/>
9. Informative References 9. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc768>. editor.org/info/rfc768>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904, D. Spence, "AAA Authorization Framework", RFC 2904,
DOI 10.17487/RFC2904, August 2000, DOI 10.17487/RFC2904, August 2000, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2904>. editor.org/info/rfc2904>.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP, Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095,
July 2001, <http://www.rfc-editor.org/info/rfc3095>. July 2001, <https://www.rfc-editor.org/info/rfc3095>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, DOI 10.17487/RFC3963, January 2005, RFC 3963, DOI 10.17487/RFC3963, January 2005,
<http://www.rfc-editor.org/info/rfc3963>. <https://www.rfc-editor.org/info/rfc3963>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4861>. editor.org/info/rfc4861>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <http://www.rfc-editor.org/info/rfc5216>. March 2008, <https://www.rfc-editor.org/info/rfc5216>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6282>. editor.org/info/rfc6282>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961, Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, DOI 10.17487/RFC6961, June 2013, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6961>. editor.org/info/rfc6961>.
[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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7252>. editor.org/info/rfc7252>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<http://www.rfc-editor.org/info/rfc7668>. <https://www.rfc-editor.org/info/rfc7668>.
[I-D.farrell-lpwan-lora-overview] [I-D.farrell-lpwan-lora-overview]
Farrell, S. and A. Yegin, "LoRaWAN Overview", draft- Farrell, S. and A. Yegin, "LoRaWAN Overview", draft-
farrell-lpwan-lora-overview-01 (work in progress), October farrell-lpwan-lora-overview-01 (work in progress), October
2016. 2016.
[I-D.minaburo-lpwan-gap-analysis] [I-D.minaburo-lpwan-gap-analysis]
Minaburo, A., Gomez, C., Toutain, L., Paradells, J., and Minaburo, A., Gomez, C., Toutain, L., Paradells, J., and
J. Crowcroft, "LPWAN Survey and GAP Analysis", draft- J. Crowcroft, "LPWAN Survey and GAP Analysis", draft-
minaburo-lpwan-gap-analysis-02 (work in progress), October minaburo-lpwan-gap-analysis-02 (work in progress), October
 End of changes. 32 change blocks. 
54 lines changed or deleted 64 lines changed or added

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