< draft-ietf-lpwan-overview-01.txt   draft-ietf-lpwan-overview-02.txt >
lpwan S. Farrell, Ed. lpwan S. Farrell, Ed.
Internet-Draft Trinity College Dublin Internet-Draft Trinity College Dublin
Intended status: Informational February 27, 2017 Intended status: Informational May 14, 2017
Expires: August 31, 2017 Expires: November 15, 2017
LPWAN Overview LPWAN Overview
draft-ietf-lpwan-overview-01 draft-ietf-lpwan-overview-02
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 August 31, 2017. This Internet-Draft will expire on November 15, 2017.
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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LPWAN Technologies . . . . . . . . . . . . . . . . . . . . . 3 2. LPWAN Technologies . . . . . . . . . . . . . . . . . . . . . 3
2.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Provenance and Documents . . . . . . . . . . . . . . 4 2.1.1. Provenance and Documents . . . . . . . . . . . . . . 4
2.1.2. Characteristics . . . . . . . . . . . . . . . . . . . 4 2.1.2. Characteristics . . . . . . . . . . . . . . . . . . . 4
2.2. Narrowband IoT (NB-IoT) . . . . . . . . . . . . . . . . . 11 2.2. Narrowband IoT (NB-IoT) . . . . . . . . . . . . . . . . . 11
2.2.1. Provenance and Documents . . . . . . . . . . . . . . 11 2.2.1. Provenance and Documents . . . . . . . . . . . . . . 11
2.2.2. Characteristics . . . . . . . . . . . . . . . . . . . 11 2.2.2. Characteristics . . . . . . . . . . . . . . . . . . . 11
2.3. SIGFOX . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3. SIGFOX . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1. Provenance and Documents . . . . . . . . . . . . . . 15 2.3.1. Provenance and Documents . . . . . . . . . . . . . . 15
2.3.2. Characteristics . . . . . . . . . . . . . . . . . . . 15 2.3.2. Characteristics . . . . . . . . . . . . . . . . . . . 15
2.4. Wi-SUN Alliance Field Area Network (FAN) . . . . . . . . 19 2.4. Wi-SUN Alliance Field Area Network (FAN) . . . . . . . . 19
2.4.1. Provenance and Documents . . . . . . . . . . . . . . 19 2.4.1. Provenance and Documents . . . . . . . . . . . . . . 20
2.4.2. Characteristics . . . . . . . . . . . . . . . . . . . 20 2.4.2. Characteristics . . . . . . . . . . . . . . . . . . . 20
3. Generic Terminology . . . . . . . . . . . . . . . . . . . . . 23 3. Generic Terminology . . . . . . . . . . . . . . . . . . . . . 23
4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 24 4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Naive application of IPv6 . . . . . . . . . . . . . . . . 24 4.1. Naive application of IPv6 . . . . . . . . . . . . . . . . 24
4.2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1. Header Compression . . . . . . . . . . . . . . . . . 25 4.2.1. Header Compression . . . . . . . . . . . . . . . . . 25
4.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 26 4.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 26
4.2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 26 4.2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 26
4.2.4. Neighbor Discovery . . . . . . . . . . . . . . . . . 27 4.2.4. Neighbor Discovery . . . . . . . . . . . . . . . . . 27
4.3. 6lo . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3. 6lo . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4. 6tisch . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.4. 6tisch . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5. RoHC . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.5. RoHC . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6. ROLL . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.6. ROLL . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.7. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.7. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 29 4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 29
4.9. DNS and LPWAN . . . . . . . . . . . . . . . . . . . . . . 29 4.9. DNS and LPWAN . . . . . . . . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
9. Informative References . . . . . . . . . . . . . . . . . . . 33 9. Informative References . . . . . . . . . . . . . . . . . . . 33
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 37 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 38
A.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 37 A.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37 A.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
[[Ed: Editor comments/queries are in double square brackets like [[Ed: Editor comments/queries are in double square brackets like
this.]] this.]]
This document provides background material and an overview of the This document provides background material and an overview of the
technologies being considered in the IETF's Low Power Wide-Area technologies being considered in the IETF's Low Power Wide-Area
Networking (LPWAN) working group. We also provide a gap analysis Networking (LPWAN) working group. We also provide a gap analysis
between the needs of these technologies and currently available IETF between the needs of these technologies and currently available IETF
specifications. specifications.
Most technologies in this space aim for similar goals of supporting Most technologies in this space aim for similar goals of supporting
large numbers of low-cost, low-throughput devices at very low-cost large numbers of low-cost, low-throughput devices at very low-cost
and with very-low power consumption, so that even battery-powered and with very-low power consumption, so that even battery-powered
devices can be deployed for years. LPWAN devices also tend to be devices can be deployed for years. LPWAN devices also tend to be
constrained in their use of bandwidth, for example with limited constrained in their use of bandwidth, for example with limited
frequencies being allowed to be used within limited duty-cycles frequencies being allowed to be used within limited duty-cycles
(usually expressed as a percentage of time/hour that the device is (usually expressed as a percentage of time per-hour that the device
allowed to transmit.) [[Ed: is that right?]] And as the name is allowed to transmit.) And as the name implies, coverage of large
implies, coverage of large areas is also a common goal. So, by and areas is also a common goal. So, by and large, the different
large, the different technologies aim for deployment in very similar technologies aim for deployment in very similar circumstances.
circumstances.
Existing pilot deployments have shown huge potential and created much Existing pilot deployments have shown huge potential and created much
industrial interest in these technolgies. As of today, [[Ed: with industrial interest in these technolgies. As of today, essentially
the possible exception of Wi-SUN devices?]] essentially no LPWAN no LPWAN devices have IP capabilities. Connecting LPWANs to the
devices have IP capabilities. Connecting LPWANs to the Internet Internet would provide significant benefits to these networks in
would provide significant benefits to these networks in terms of terms of interoperability, application deployment, and management,
interoperability, application deployment, and management, among among others. The goal of the LPWAN WG is to, where necessary, adapt
others. The goal of the LPWAN WG is to, where necessary, adapt IETF IETF defined protocols, addressing schemes and naming to this
defined protocols, addressing schemes and naming to this particular particular constrained environment.
constrained environment.
This document is largely the work of the people listed in Section 7. This document is largely the work of the people listed in Section 7.
Discussion of this document should take place on the lp-wan@ietf.org Discussion of this document should take place on the lp-wan@ietf.org
list. list.
2. LPWAN Technologies 2. LPWAN Technologies
This section provides an overview of the set of LPWAN technologies This section provides an overview of the set of LPWAN technologies
that are being considered in the LPWAN working group. The text for that are being considered in the LPWAN working group. The text for
each was mainly contributed by proponents of each technology. each was mainly contributed by proponents of each technology.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
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 a wireless technology for long-range low-power low-data-
rate applications developed by the LoRa Alliance, a membership rate applications developed by the LoRa Alliance, a membership
consortium. <https://www.lora-alliance.org/> This draft is based on consortium. <https://www.lora-alliance.org/> This draft is based on
version 1.0.2 [LoRaSpec] of the LoRa specification. Version 1.0, version 1.0.2 [LoRaSpec] of the LoRa specification. Version 1.0,
which has also seen some deployment, is available at [LoRaSpec1.0]. which has also seen some deployment, is available at [LoRaSpec1.0].
2.1.2. Characteristics 2.1.2. Characteristics
In LoRaWAN networks, end-device transmissions may be received at
multiple gateways, so during nominal operation a network server may
see multiple instances of the same uplink message from an end-device.
The LoRaWAN network infrastructure manages the data rate and RF
output power for each end-device individually by means of an adaptive
data rate (ADR) scheme. End-devices may transmit on any channel
allowed by local regulation at any time, using any of the currently
available data rates.
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. All communication that can be received at one or more gateways. All
communication is generally bi-directional, although uplink communication is generally bi-directional, although uplink
communication from end-devices to the network server are favoured in communication from end-devices to the network server are favoured in
terms of overall bandwidth availability. terms of overall 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 5, line 45 skipping to change at page 5, line 22
o Downlink message: refers to communications from network server or o Downlink message: refers to communications from network server or
application via one gateway to a single end-device or a group of application via one gateway to a single end-device or a group of
end-devices (considering multicasting). end-devices (considering multicasting).
o Application: refers to application layer code both on the end- o Application: refers to application layer code both on the end-
device and running "behind" the network server. For LoRaWAN, device and running "behind" the network server. For LoRaWAN,
there will generally only be one application running on most end- there will generally only be one application running on most end-
devices. Interfaces between the network server and application devices. Interfaces between the network server and application
are not further described here. are not further described here.
In LoRaWAN networks, end-device transmissions may be received at
multiple gateways, so during nominal operation a network server may
see multiple instances of the same uplink message from an end-device.
The LoRaWAN network infrastructure manages the data rate and RF
output power for each end-device individually by means of an adaptive
data rate (ADR) scheme. End-devices may transmit on any channel
allowed by local regulation at any time.
LoRaWAN radios make use of industrial, scientific and medical (ISM) LoRaWAN radios make use of industrial, scientific and medical (ISM)
bands, for example, 433MHz and 868MHz within the European Union and bands, for example, 433MHz and 868MHz within the European Union and
915MHz in the Americas. 915MHz in the Americas.
The end-device changes channel in a pseudo-random fashion for every The end-device changes channel in a pseudo-random fashion for every
transmission to help make the system more robust to interference and/ transmission to help make the system more robust to interference and/
or to conform to local regulations. or to conform to local regulations.
Figure 2 below shows that after a transmission slot a Class A device Figure 2 below shows that after a transmission slot a Class A device
turns on its receiver for two short receive windows that are offset turns on its receiver for two short receive windows that are offset
skipping to change at page 8, line 19 skipping to change at page 8, line 19
power status with the response from the end-device specifying whether power status with the response from the end-device specifying whether
it has an external power source or is battery powered (in which case it has an external power source or is battery powered (in which case
a relative battery level is also sent to the network server). a relative battery level is also sent to the network server).
A LoRaWAN network has a short network identifier ("NwkID") which is a A LoRaWAN network has a short network identifier ("NwkID") which is a
seven bit value. A private network (common for LoRaWAN) can use the seven bit value. A private network (common for LoRaWAN) can use the
value zero. If a network wishes to support "foreign" end-devices value zero. If a network wishes to support "foreign" end-devices
then the NwkID needs to be registered with the LoRA Alliance, in then the NwkID needs to be registered with the LoRA Alliance, in
which case the NwkID is the seven least significant bits of a which case the NwkID is the seven least significant bits of a
registered 24-bit NetID. (Note however, that the methods for registered 24-bit NetID. (Note however, that the methods for
"roaming" are defined in the upcoming LoRaWAN 1.1 specification. "roaming" are defined in the upcoming LoRaWAN 1.1 specification.)
In order to operate nominally on a LoRaWAN network, a device needs a In order to operate nominally on a LoRaWAN network, a device needs a
32-bit device address, which is the catentation of the NwkID and a 32-bit device address, which is the catentation of the NwkID and a
25-bit device-specific network address that is assigned when the 25-bit device-specific network address that is assigned when the
device "joins" the network (see below for the join procedure) or that device "joins" the network (see below for the join procedure) or that
is pre-provisioned into the device. is pre-provisioned into the device.
End-devices are assumed to work with one or a quite limited number of End-devices are assumed to work with one or a quite limited number of
applications, identified by a 64-bit AppEUI, which is assumed to be a applications, identified by a 64-bit AppEUI, which is assumed to be a
registered IEEE EUI64 value. In addition, a device needs to have two registered IEEE EUI64 value. In addition, a device needs to have two
skipping to change at page 18, line 24 skipping to change at page 18, line 24
A device willing to receive downlink messages opens a fixed window A device willing to receive downlink messages opens a fixed window
for reception after sending an uplink transmission. The delay and for reception after sending an uplink transmission. The delay and
duration of this window have fixed values. The LTN transmits the duration of this window have fixed values. The LTN transmits the
downlink message for a given device during the reception window. The downlink message for a given device during the reception window. The
LTN selects the base station (BS) for transmitting the corresponding LTN selects the base station (BS) for transmitting the corresponding
downlink message. downlink message.
Uplink and downlink transmissions are unbalanced due to the Uplink and downlink transmissions are unbalanced due to the
regulatory constraints on the ISM bands. Under the strictest regulatory constraints on the ISM bands. Under the strictest
regulations, the system can allow a maximum of 140 uplink messages regulations, the system can allow a maximum of 140 uplink messages
and 4 downlink messages per device. [[Ed: in what duration?]] These and 4 downlink messages per device per day. These restrictions can
restrictions can be slightly relaxed depending on system conditions be slightly relaxed depending on system conditions and the specific
and the specific regulatory domain of operation. regulatory domain of operation.
+--+ +--+
|EP| * +------+ |EP| * +------+
+--+ * | RA | +--+ * | RA |
* +------+ * +------+
+--+ * | +--+ * |
|EP| * * * * | |EP| * * * * |
+--+ * +----+ | +--+ * +----+ |
* | BS | \ +--------+ * | BS | \ +--------+
+--+ * +----+ \ | | +--+ * +----+ \ | |
skipping to change at page 19, line 45 skipping to change at page 19, line 45
message has been generated and sent by the device with the ID claimed message has been generated and sent by the device with the ID claimed
in the message. in the message.
Security keys are independent for each device. These keys are Security keys are independent for each device. These keys are
associated with the device ID and they are pre-provisioned. associated with the device ID and they are pre-provisioned.
Application data can be encrypted by the application provider. Application data can be encrypted by the application provider.
2.4. Wi-SUN Alliance Field Area Network (FAN) 2.4. Wi-SUN Alliance Field Area Network (FAN)
[[Ed: Text here is via personal communication from Bob Heile [[Ed: Text here is via personal communication from Bob Heile
(bheile@ieee.org) and was authored by Bob and Sum Chin Sean. Many (bheile@ieee.org) and was authored by Bob and Sum Chin Sean. The
references to specifications are still needed here.]] editor thanks Paul Duffy (paduffy@cisco.com) for forwarding updated
text from Bob and additional comments/input on this section. ]]
2.4.1. Provenance and Documents 2.4.1. Provenance and Documents
The Wi-SUN Alliance <https://www.wi-sun.org/> is an industry alliance The Wi-SUN Alliance <https://www.wi-sun.org/> is an industry alliance
for smart city, smart grid, smart utility, and a broad set of general for smart city, smart grid, smart utility, and a broad set of general
IoT applications. The Wi-SUN Alliance Field Area Network (FAN) IoT applications. The Wi-SUN Alliance Field Area Network (FAN)
profile is open standards based (primarily on IETF and IEEE802 profile is open standards based (primarily on IETF and IEEE802
standards) and was developed to address applications like smart standards) and was developed to address applications like smart
municipality/city infrastructure monitoring and management, electric municipality/city infrastructure monitoring and management, electric
vehicle (EV) infrastructure, advanced metering infrastructure (AMI), vehicle (EV) infrastructure, advanced metering infrastructure (AMI),
distribution automation (DA), supervisory control and data distribution automation (DA), supervisory control and data
acquisition (SCADA) protection/management, distributed generation acquisition (SCADA) protection/management, distributed generation
monitoring and management, and many more IoT applications. monitoring and management, and many more IoT applications.
Additionally, the Alliance has created a certification program to Additionally, the Alliance has created a certification program to
promote global multi-vendor interoperability. promote global multi-vendor interoperability.
The FAN profile [[Ed: reference (really really:-) needed!]] is an The FAN profiile is currently being specified within ANSI/TIA as an
IPv6 frequency hopping wireless mesh network with support for extension of work previously done on Smart Utility Networks.
enterprise level security. The frequency hopping wireless mesh [ANSI-4957-000]. Updates to those specifications intended to be
topology aims to offer superior network robustness, reliability due published in 2017 will contain details of the FAN profile. A current
to high redundancy, good scalability due to the flexible mesh snapshot of the work to produce that profile is presented in
configuration and good resilience to interference. Very low power [wisun-pressie1] [wisun-pressie2] .
modes are in development permitting long term battery operation of
network nodes. [[Ed: details welcome.]]
2.4.2. Characteristics 2.4.2. Characteristics
[[Ed: this really needs the references.]] The FAN profile is based on The FAN profile is an IPv6 frequency hopping wireless mesh network
various open standards in IETF, IEEE802 and ANSI/TIA for low power with support for enterprise level security. The frequency hopping
and lossy networks. The FAN profile specification provides an wireless mesh topology aims to offer superior network robustness,
application-independent IPv6-based transport service for both reliability due to high redundancy, good scalability due to the
connectionless (i.e. UDP) and connection-oriented (i.e. TCP) flexible mesh configuration and good resilience to interference.
services. There are two possible methods for establishing the IPv6 Very low power modes are in development permitting long term battery
packet routing: mandatory Routing Protocol for Low-Power and Lossy operation of network nodes.
Networks (RPL) at the Network layer or optional Multi-Hop Delivery
Service (MHDS) at the Data Link layer. Table 5 provides an overview The core architecture of Wi-SUN FAN is a mesh network. A FAN
of the FAN network stack. contains one or more networks. Within a network, nodes assume one of
three operational roles. First, each network contains a Border
Router providing Wide Area Network (WAN) connectivity to the network.
The Border Router maintains source routing tables for all nodes
within its network, provides node authentication and key management
services, and disseminates network-wide information such as broadcast
schedules. Secondly, Router nodes, which provide upward and downward
packet forwarding (within a network). A Router also provides
services for relaying security and address management protocols.
Lastly, Leaf nodes provide minimum capabilities: discovering and
joining a network, send/receive IPv6 packets, etc. A low power
network may contain a mesh topology with Routers at the edges that
construct star topology with Leaf nodes.
The FAN profile is based on various open standards developed by the
IETF (including [RFC0768], [RFC2460], [RFC4443] and [RFC6282]),
IEEE802 (including [IEEE-802-15-4] and [IEEE-802-15-9]) and ANSI/TIA
[ANSI-4957-210] for low power and lossy networks.
The FAN profile specification provides an application-independent
IPv6-based transport service for both connectionless (i.e. UDP) and
connection-oriented (i.e. TCP) services. There are two possible
methods for establishing the IPv6 packet routing: mandatory Routing
Protocol for Low-Power and Lossy Networks (RPL) at the Network layer
or optional Multi-Hop Delivery Service (MHDS) at the Data Link layer.
Table 5 provides an overview of the FAN network stack.
The Transport service is based on User Datagram Protocol (UDP) The Transport service is based on User Datagram Protocol (UDP)
defined in RFC768 or Transmission Control Protocol (TCP) defined in defined in RFC768 or Transmission Control Protocol (TCP) defined in
RFC793. RFC793.
The Network service is provided by IPv6 defined in RFC2460 with The Network service is provided by IPv6 defined in RFC2460 with
6LoWPAN adaptation as defined in RC4944 and RFC6282. Additionally, 6LoWPAN adaptation as defined in RC4944 and RFC6282. Additionally,
ICMPv6 as defined in RFC4443 is used for control plane in information ICMPv6 as defined in RFC4443 is used for control plane in information
exchange. exchange.
skipping to change at page 21, line 4 skipping to change at page 21, line 34
ICMPv6 as defined in RFC4443 is used for control plane in information ICMPv6 as defined in RFC4443 is used for control plane in information
exchange. exchange.
The Data Link service provides both control/management of the The Data Link service provides both control/management of the
Physical layer and data transfer/management services to the Network Physical layer and data transfer/management services to the Network
layer. These services are divided into Media Access Control (MAC) layer. These services are divided into Media Access Control (MAC)
and Logical Link Control (LLC) sub-layers. The LLC sub-layer and Logical Link Control (LLC) sub-layers. The LLC sub-layer
provides a protocol dispatch service which supports 6LoWPAN and an provides a protocol dispatch service which supports 6LoWPAN and an
optional MAC sub-layer mesh service. The MAC sub-layer is optional MAC sub-layer mesh service. The MAC sub-layer is
constructed using data structures defined in IEEE802.15.4-2015. constructed using data structures defined in IEEE802.15.4-2015.
Multiple modes of frequency hopping are defined. The entire MAC Multiple modes of frequency hopping are defined. The entire MAC
payload is encapsulated in an IEEE802.15.9 Information Element to payload is encapsulated in an IEEE802.15.9 Information Element to
enable LLC protocol dispatch between upper layer 6LoWPAN processing, enable LLC protocol dispatch between upper layer 6LoWPAN processing,
MAC sublayer mesh processing, etc. These areas will be expanded once MAC sublayer mesh processing, etc. These areas will be expanded once
IEEE802.15.12 is completed IEEE802.15.12 is completed
The PHY service is derived from a sub-set of the SUN FSK The PHY service is derived from a sub-set of the SUN FSK
specification in IEEE802.15.4-2015. The 2-FSK modulation schemes, specification in IEEE802.15.4-2015. The 2-FSK modulation schemes,
with channel spacing range from 200 to 600 kHz, are defined to with channel spacing range from 200 to 600 kHz, are defined to
provide data rates from 50 to 300 kbps, with Forward Error Coding provide data rates from 50 to 300 kbps, with Forward Error Coding
(FEC) as an optional feature. Towards enabling ultra-low-power (FEC) as an optional feature. Towards enabling ultra-low-power
applications, the PHY layer design is also extendable to low energy applications, the PHY layer design is also extendable to low energy
and critical infrastructure monitoring networks, such as and critical infrastructure monitoring networks.
IEEE802.15.4k.
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
| Layer | Description | | Layer | Description |
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
| IPv6 protocol suite | TCP/UDP | | IPv6 protocol suite | TCP/UDP |
| | | | | |
| | 6LoWPAN Adaptation + Header | | | 6LoWPAN Adaptation + Header |
| | Compression | | | Compression |
| | | | | |
| | DHCPv6 for IP address management. | | | DHCPv6 for IP address management. |
skipping to change at page 22, line 44 skipping to change at page 22, line 44
| | | | | |
| Security | 802.1X/EAP-TLS/PKI | | Security | 802.1X/EAP-TLS/PKI |
| | Authentication. | | | Authentication. |
| | | | | |
| | 802.11i Group Key Management | | | 802.11i Group Key Management |
| | | | | |
| | Optional ETSI-TS-102-887-2 Node 2 | | | Optional ETSI-TS-102-887-2 Node 2 |
| | Node Key Management | | | Node Key Management |
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
Table 5: Wi-SUN Stack Overivew Table 5: Wi-SUN Stack Overview
The FAN security supports Data Link layer network access control, The FAN security supports Data Link layer network access control,
mutual authentication, and establishment of a secure pairwise link mutual authentication, and establishment of a secure pairwise link
between a FAN node and its Border Router, which is implemented with between a FAN node and its Border Router, which is implemented with
an adaptation of IEEE802.1X and EAP-TLS as described in RFC5216 using an adaptation of IEEE802.1X and EAP-TLS as described in [RFC5216]
secure device identity as described in IEEE802.1AR. Certificate using secure device identity as described in IEEE802.1AR.
formats are based upon RFC5280. A secure group link between a Border Certificate formats are based upon [RFC5280]. A secure group link
Router and a set of FAN nodes is established using an adaptation of between a Border Router and a set of FAN nodes is established using
the IEEE802.11 Four-Way Handshake. A set of 4 group keys are an adaptation of the IEEE802.11 Four-Way Handshake. A set of 4 group
maintained within the network, one of which is the current transmit keys are maintained within the network, one of which is the current
key. Secure node to node links are supported between one-hop FAN transmit key. Secure node to node links are supported between one-
neighbors using an adaptation of ETSI-TS-102-887-2. FAN nodes hop FAN neighbors using an adaptation of ETSI-TS-102-887-2. FAN
implement Frame Security as specified in IEEE802.15.4-2015. nodes implement Frame Security as specified in IEEE802.15.4-2015.
3. Generic Terminology 3. Generic Terminology
LPWAN technologies, such as those discussed above, have similar LPWAN technologies, such as those discussed above, have similar
architectures but different terminology. We can identify different architectures but different terminology. We can identify different
types of entities in a typical LPWAN network: types of entities in a typical LPWAN network:
o The Host, which are the devices or the things (e.g. sensors, o End-Devices are the devices or the "things" (e.g. sensors,
actuators, etc.), they are named differently in each technology actuators, etc.), they are named differently in each technology
(End Device, User Equipment or End Point). There can be a high (End Device, User Equipment or End Point). There can be a high
density of hosts per radio gateway. density of end devices per radio gateway.
o The Radio Gateway, which is the end point of the constrained link. o The Radio Gateway, which is the end point of the constrained link.
It is known as: Gateway, Evolved Node B or Base station. It is known as: Gateway, Evolved Node B or Base station.
o The Network Gateway or Router is the interconnection node between o The Network Gateway or Router is the interconnection node between
the Radio Gateway and the Internet. It is known as: Network the Radio Gateway and the Internet. It is known as: Network
Server, Serving GW or Service Center. Server, Serving GW or Service Center.
o AAA Server, which controls the user authentication, the o AAA Server, which controls the user authentication, the
applications. It is known as: Join-Server, Home Subscriber Server applications. It is known as: Join-Server, Home Subscriber Server
skipping to change at page 24, line 42 skipping to change at page 24, line 42
() () () | | <--|--> | +------+ |Application| () () () | | <--|--> | +------+ |Application|
() () () () / \============| v |==============| Server | () () () () / \============| v |==============| Server |
() () () / \ +---------+ +-----------+ () () () / \ +---------+ +-----------+
HOSTS Radio Gateways Network Gateway HOSTS Radio Gateways Network Gateway
Figure 9: LPWAN Architecture Figure 9: LPWAN Architecture
In addition to the names of entities, LPWANs are also subject to In addition to the names of entities, LPWANs are also subject to
possibly regional frequency band regulations. Those may include possibly regional frequency band regulations. Those may include
restrictions on the duty-cycle, for example requiring that hosts only restrictions on the duty-cycle, for example requiring that hosts only
transmit for a certain percentage of each hour. [[Ed: Are these transmit for a certain percentage of each hour.
duty-cycle percentages always per-hour? Could a host amortise it's
transmits per day?]]
4. Gap Analysis 4. Gap Analysis
4.1. Naive application of IPv6 4.1. Naive application of IPv6
IPv6 [RFC2460] has been designed to allocate addresses to all the IPv6 [RFC2460] has been designed to allocate addresses to all the
nodes connected to the Internet. Nevertheless, the header overhead nodes connected to the Internet. Nevertheless, the header overhead
of at least 40 bytes introduced by the protocol is incompatible with of at least 40 bytes introduced by the protocol is incompatible with
LPWAN constraints. If IPv6 with no further optimization were used, LPWAN constraints. If IPv6 with no further optimization were used,
several LPWAN frames would be needed just to carry the IP header. several LPWAN frames would be needed just to carry the IP header.
skipping to change at page 28, line 7 skipping to change at page 27, line 51
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.
6lo has mostly used the subset of 6LoWPAN techniques best suited for 6lo has mostly used the subset of 6LoWPAN techniques best suited for
each lower layer technology, and has provided additional each lower layer technology, and has provided additional
optimizations for technologies where the star topology is used, such optimizations for technologies where the star topology is used, such
as BTLE or DECT-ULE. as BTLE or DECT-ULE.
The main constraint in these networks comes from the nature of the The main constraint in these networks comes from the nature of the
devices (constrained devices), whereas in LPWANs it is the network devices (constrained devices), whereas in LPWANs it is the network
itself that imposes the most stringent constraints. [[Ed: I'm not itself that imposes the most stringent constraints.
sure that conclusion follows from the information provided in this
section - is more needed?.]]
4.4. 6tisch 4.4. 6tisch
The 6tisch solution is dedicated to mesh networks that operate using The 6tisch solution is dedicated to mesh networks that operate using
802.15.4e MAC with a deterministic slotted channel. The time slot 802.15.4e MAC with a deterministic slotted channel. The time slot
channel (TSCH) can help to reduce collisions and to enable a better channel (TSCH) can help to reduce collisions and to enable a better
balance over the channels. It improves the battery life by avoiding balance over the channels. It improves the battery life by avoiding
the idle listening time for the return channel. the idle listening time for the return channel.
A key element of 6tisch is the use of synchronization to enable A key element of 6tisch is the use of synchronization to enable
skipping to change at page 28, line 48 skipping to change at page 28, line 42
of the level of compression. When packets are lost or errored, the of the level of compression. When packets are lost or errored, the
decompressor loses context and drops packets until a bigger header is decompressor loses context and drops packets until a bigger header is
sent with more complete information. To estimate the performance of sent with more complete information. To estimate the performance of
RoHC, an average header size is used. This average depends on the RoHC, an average header size is used. This average depends on the
transmission conditions, but most of the time is between 3 and 4 transmission conditions, but most of the time is between 3 and 4
bytes. bytes.
RoHC has not been adapted specifically to the constrained hosts and RoHC has not been adapted specifically to the constrained hosts and
networks of LPWANs: it does not take into account energy limitations networks of LPWANs: it does not take into account energy limitations
nor the transmission rate, and RoHC context is synchronised during nor the transmission rate, and RoHC context is synchronised during
transmission, which does not allow better compression. [[Ed: this transmission, which does not allow better compression.
seems to conflict a bit with what was said about 6tisch which puzzled
me.]]
4.6. ROLL 4.6. ROLL
Most technologies considered by the lpwan WG are based on a star Most technologies considered by the lpwan WG are based on a star
topology, which eliminates the need for routing at that layer. topology, which eliminates the need for routing at that layer.
Future work may address additional use-cases that may require Future work may address additional use-cases that may require
adaptation of existing routing protocols or the definition of new adaptation of existing routing protocols or the definition of new
ones. As of the time of writing, work similar to that done in the ones. As of the time of writing, work similar to that done in the
ROLL WG and other routing protocols are out of scope of the LPWAN WG. ROLL WG and other routing protocols are out of scope of the LPWAN WG.
skipping to change at page 29, line 47 skipping to change at page 29, line 38
most of the time the node will be down. The mobility will imply most most of the time the node will be down. The mobility will imply most
of the time a group of devices, which represent a network itself. of the time a group of devices, which represent a network itself.
The mobility concerns more the gateway than the devices. The mobility concerns more the gateway than the devices.
NEMO [RFC3963] Mobility solutions may be used in the case where some NEMO [RFC3963] Mobility solutions may be used in the case where some
hosts belonging to the same Network gateway will move from one point hosts belonging to the same Network gateway will move from one point
to another and that they are not aware of this mobility. to another and that they are not aware of this mobility.
4.9. DNS and LPWAN 4.9. DNS and LPWAN
[[Ed: the WG probably need to decide what to say about DNS, there's
not much content here so far.]]
The Domain Name System (DNS) DNS [RFC1035], enables applications to The Domain Name System (DNS) DNS [RFC1035], enables applications to
name things with a globallly resolvable name. Many protocols use the name things with a globallly resolvable name. Many protocols use the
DNS to identify hosts for example applications using CoAP. DNS to identify hosts for example applications using CoAP.
The DNS query/answer protocol as a pre-cursor to other communication The DNS query/answer protocol as a pre-cursor to other communication
within the time-to-live (TTL) of a DNS answer is clearly problematic within the time-to-live (TTL) of a DNS answer is clearly problematic
in an LPWAN, say where only one round-trip per hour can be used, and in an LPWAN, say where only one round-trip per hour can be used, and
with a TTL that is less than 3600. It is currently unclear [[Ed: to with a TTL that is less than 3600. It is currently unclear whether
me anyway:-)]] whether and hw DNS-like functionality might be and how DNS-like functionality might be provided in LPWANs.
provided in LPWANs.
5. Security Considerations 5. Security Considerations
[[Ed: be good to add stuff here about a) privacy and b) difficulties
with getting current security protocols to work in this context. For
a) maybe try find nice illustrations, e.g. extremecom instrumeted-
igloo traces (temperature change allowing one to infer when someone
took a pee:-). For b) things like IPsec/(D)TLS/OCSP and NTP to work
in these environments. Not sure how much of that is known or useful
for the WG. Probably worth noting the IAB statement on
confidentiality and to ponder the impact of more than one layer of
encryption in this context. Text below is basically from the "gaps"
draft.]]
Most LPWAN technologies integrate some authentication or encryption Most LPWAN technologies integrate some authentication or encryption
mechanisms that were defined outside the IETF. The working group may mechanisms that were defined outside the IETF. The working group may
need to do work to integrate these mechanisms to unify management. A need to do work to integrate these mechanisms to unify management. A
standardized Authentication, Accounting and Authorization (AAA) standardized Authentication, Accounting and Authorization (AAA)
infrastructure [RFC2904] may offer a scalable solution for some of infrastructure [RFC2904] may offer a scalable solution for some of
the security and management issues for LPWANs. AAA offers the security and management issues for LPWANs. AAA offers
centralized management that may be of use in LPWANs, for example centralized management that may be of use in LPWANs, for example
[I-D.garcia-dime-diameter-lorawan] and [I-D.garcia-dime-diameter-lorawan] and
[I-D.garcia-radext-radius-lorawan] suggest possible security [I-D.garcia-radext-radius-lorawan] suggest possible security
processes for a LoRaWAN network. Similar mechanisms may be useful to processes for a LoRaWAN network. Similar mechanisms may be useful to
explore for other LPWAN technologies. explore for other LPWAN technologies.
Some applications using LPWANs may raise few or no privacy
considerations. For example, temperature sensors in a large office
building may not raise privacy issues. However, the same sensors, if
deployed in a home environment and especially if triggered due to
human presence, can raise significant privacy issues - if an end-
device emits (an encrypted) packet every time someone enters a room
in a home, then that traffic is privacy sensitive. And the more that
the existence of that traffic is visible to network entities, the
more privacy sensitivities arise. At this point, it is not clear
whether there are workable mitigations for problems like this - in a
more typical network, one would cosider defining padding mechanisms
and allowing for cover traffic. In some LPWANs, those mechanisms may
not be feasible. Nonetheless, the privacy challenges do exist and
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
specifications, but can be e.g. implementation or deployment
specific.
Another challenge for LPWANs will be how to handle key management and
associated protocols. In a more traditional network (e.g. the web),
servers can stable OCSP responses in order to allow browsers to check
revocation status for presented certificates. [RFC6961] While the
"stapling" approach is likely something that would help in an LPWAN,
as it avoids an RTT, certificates and OCSP responses are bulky items
and will prove 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 33, line 33 skipping to change at page 33, line 38
Errors in the handling of that are solely the editor's fault. Errors in the handling of that are solely the editor's fault.
In addition to the contributors above, thanks are due to Jiazi Yi, In addition to the contributors above, thanks are due to Jiazi Yi,
[your name here] for comments. [your name here] for comments.
Stephen Farrell's work on this memo was supported by the Science Stephen Farrell's work on this memo was supported by the Science
Foundation Ireland funded CONNECT centre <https://connectcentre.ie/>. Foundation Ireland funded CONNECT centre <https://connectcentre.ie/>.
9. Informative References 9. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-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, <http://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, <http://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
skipping to change at page 34, line 27 skipping to change at page 34, line 33
[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>. <http://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, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://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,
<http://www.rfc-editor.org/info/rfc4861>. <http://www.rfc-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>. <http://www.rfc-editor.org/info/rfc4944>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <http://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,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://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,
<http://www.rfc-editor.org/info/rfc6282>. <http://www.rfc-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>. <http://www.rfc-editor.org/info/rfc6775>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-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,
<http://www.rfc-editor.org/info/rfc7252>. <http://www.rfc-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>. <http://www.rfc-editor.org/info/rfc7668>.
skipping to change at page 35, line 28 skipping to change at page 36, line 7
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
2016. 2016.
[I-D.zuniga-lpwan-sigfox-system-description] [I-D.zuniga-lpwan-sigfox-system-description]
Zuniga, J. and B. PONSARD, "SIGFOX System Description", Zuniga, J. and B. PONSARD, "SIGFOX System Description",
draft-zuniga-lpwan-sigfox-system-description-01 (work in draft-zuniga-lpwan-sigfox-system-description-02 (work in
progress), October 2016. progress), March 2017.
[I-D.ratilainen-lpwan-nb-iot] [I-D.ratilainen-lpwan-nb-iot]
Ratilainen, A., "NB-IoT characteristics", draft- Ratilainen, A., "NB-IoT characteristics", draft-
ratilainen-lpwan-nb-iot-00 (work in progress), July 2016. ratilainen-lpwan-nb-iot-00 (work in progress), July 2016.
[I-D.garcia-dime-diameter-lorawan] [I-D.garcia-dime-diameter-lorawan]
Garcia, D., Lopez, R., Kandasamy, A., and A. Pelov, Garcia, D., Lopez, R., Kandasamy, A., and A. Pelov,
"LoRaWAN Authentication in Diameter", draft-garcia-dime- "LoRaWAN Authentication in Diameter", draft-garcia-dime-
diameter-lorawan-00 (work in progress), May 2016. diameter-lorawan-00 (work in progress), May 2016.
[I-D.garcia-radext-radius-lorawan] [I-D.garcia-radext-radius-lorawan]
Garcia, D., Lopez, R., Kandasamy, A., and A. Pelov, Garcia, D., Lopez, R., Kandasamy, A., and A. Pelov,
"LoRaWAN Authentication in RADIUS", draft-garcia-radext- "LoRaWAN Authentication in RADIUS", draft-garcia-radext-
radius-lorawan-02 (work in progress), October 2016. radius-lorawan-03 (work in progress), May 2017.
[TGPP36300] [TGPP36300]
3GPP, "TS 36.300 v13.4.0 Evolved Universal Terrestrial 3GPP, "TS 36.300 v13.4.0 Evolved Universal Terrestrial
Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial
Radio Access Network (E-UTRAN); Overall description; Stage Radio Access Network (E-UTRAN); Overall description; Stage
2", 2016, 2", 2016,
<http://www.3gpp.org/ftp/Specs/2016-09/Rel-14/36_series/>. <http://www.3gpp.org/ftp/Specs/2016-09/Rel-14/36_series/>.
[TGPP36321] [TGPP36321]
3GPP, "TS 36.321 v13.2.0 Evolved Universal Terrestrial 3GPP, "TS 36.321 v13.2.0 Evolved Universal Terrestrial
skipping to change at page 37, line 21 skipping to change at page 38, line 5
LoRa Alliance, "LoRaWAN Specification Version V1.0.2", LoRa Alliance, "LoRaWAN Specification Version V1.0.2",
July 2016, <http://portal.lora- July 2016, <http://portal.lora-
alliance.org/DesktopModules/Inventures_Document/ alliance.org/DesktopModules/Inventures_Document/
FileDownload.aspx?ContentID=1398>. FileDownload.aspx?ContentID=1398>.
[LoRaSpec1.0] [LoRaSpec1.0]
LoRa Alliance, "LoRaWAN Specification Version V1.0", Jan LoRa Alliance, "LoRaWAN Specification Version V1.0", Jan
2015, <https://www.lora-alliance.org/portals/0/specs/ 2015, <https://www.lora-alliance.org/portals/0/specs/
LoRaWAN%20Specification%201R0.pdf>. LoRaWAN%20Specification%201R0.pdf>.
[ANSI-4957-000]
ANSI, TIA-4957.000, "Architecture Overview for the Smart
Utility Network", May 2013, <https://global.ihs.com/
doc_detail.cfm?%26rid=TIA%26item_s_key=00606368>.
[ANSI-4957-210]
ANSI, TIA-4957.210, "Multi-Hop Delivery Specification of a
Data Link Sub-Layer", May 2013, <https://global.ihs.com/
doc_detail.cfm?%26csf=TIA%26item_s_key=00601800>.
[wisun-pressie1]
Phil Beecher, Chair, Wi-SUN Alliance, "Wi-SUN Alliance
Overview", March 2017, <http://indiasmartgrid.org/event201
7/10-03-2017/4.%20Roundtable%20on%20Communication%20and%20
Cyber%20Security/1.%20Phil%20Beecher.pdf>.
[wisun-pressie2]
Bob Heile, Director of Standards, Wi-SUN Alliance, "IETF97
Wi-SUN Alliance Field Area Network (FAN) Overview",
November 2016,
<https://www.ietf.org/proceedings/97/slides/slides-97-
lpwan-35-wi-sun-presentation-00.pdf>.
[IEEE-802-15-4]
"IEEE Standard for Low-Rate Wireless Personal Area
Networks (WPANs)", IEEE Standard 802.15.4, 2015,
<https://standards.ieee.org/findstds/
standard/802.15.4-2015.html>.
[IEEE-802-15-9]
"IEEE Recommended Practice for Transport of Key Management
Protocol (KMP) Datagrams", IEEE Standard 802.15.9, 2016,
<https://standards.ieee.org/findstds/
standard/802.15.9-2016.html>.
Appendix A. Changes Appendix A. Changes
A.1. From -00 to -01 A.1. From -00 to -01
o WG have stated they want this to be an RFC. o WG have stated they want this to be an RFC.
o WG clearly want to keep the RF details. o WG clearly want to keep the RF details.
o Various changes made to remove/resolve a number of editorial notes o Various changes made to remove/resolve a number of editorial notes
from -00 (in some cases as per suggestions from Ana Minaburo) from -00 (in some cases as per suggestions from Ana Minaburo)
o Merged PR's: #1... o Merged PR's: #1...
o Rejected PR's: #2 (change was made to .txt not .xml but was
replicated manually by editor)
o Github repo is at: https://github.com/sftcd/lpwan-ov o Github repo is at: https://github.com/sftcd/lpwan-ov
A.2. From -01 to -02
o WG seem to agree with editor suggestions in slides 13-24 of the
presentation on this topic given at IETF98 (See:
https://www.ietf.org/proceedings/98/slides/slides-98-lpwan-
aggregated-slides-07.pdf)
o Got new text wrt Wi-SUN via email from Paul Duffy and merged that
in
o Reflected list discussion wrt terminology and "end-device"
o Merged PR's: #3...
Author's Address Author's Address
Stephen Farrell (editor) Stephen Farrell (editor)
Trinity College Dublin Trinity College Dublin
Dublin 2 Dublin 2
Ireland Ireland
Phone: +353-1-896-2354 Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie Email: stephen.farrell@cs.tcd.ie
 End of changes. 41 change blocks. 
102 lines changed or deleted 206 lines changed or added

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