< draft-ietf-lpwan-overview-07.txt   draft-ietf-lpwan-overview-08.txt >
lpwan S. Farrell, Ed. lpwan S. Farrell, Ed.
Internet-Draft Trinity College Dublin Internet-Draft Trinity College Dublin
Intended status: Informational October 3, 2017 Intended status: Informational January 30, 2018
Expires: April 6, 2018 Expires: August 3, 2018
LPWAN Overview LPWAN Overview
draft-ietf-lpwan-overview-07 draft-ietf-lpwan-overview-08
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 April 6, 2018. This Internet-Draft will expire on August 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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) . . . . . . . . . . . . . . . . . 10 2.2. Narrowband IoT (NB-IoT) . . . . . . . . . . . . . . . . . 11
2.2.1. Provenance and Documents . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 16
2.4. Wi-SUN Alliance Field Area Network (FAN) . . . . . . . . 20 2.4. Wi-SUN Alliance Field Area Network (FAN) . . . . . . . . 20
2.4.1. Provenance and Documents . . . . . . . . . . . . . . 20 2.4.1. Provenance and Documents . . . . . . . . . . . . . . 20
2.4.2. Characteristics . . . . . . . . . . . . . . . . . . . 21 2.4.2. Characteristics . . . . . . . . . . . . . . . . . . . 21
3. Generic Terminology . . . . . . . . . . . . . . . . . . . . . 24 3. Generic Terminology . . . . . . . . . . . . . . . . . . . . . 24
4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 25 4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1. Naive application of IPv6 . . . . . . . . . . . . . . . . 26 4.1. Naive application of IPv6 . . . . . . . . . . . . . . . . 26
4.2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1. Header Compression . . . . . . . . . . . . . . . . . 27 4.2.1. Header Compression . . . . . . . . . . . . . . . . . 27
4.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 27 4.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 27
4.2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 27 4.2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 27
4.2.4. Neighbor Discovery . . . . . . . . . . . . . . . . . 28 4.2.4. Neighbor Discovery . . . . . . . . . . . . . . . . . 28
4.3. 6lo . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3. 6lo . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4. 6tisch . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.4. 6tisch . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5. RoHC . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.5. RoHC . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6. ROLL . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.6. ROLL . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.7. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.7. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 30 4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 30
4.9. DNS and LPWAN . . . . . . . . . . . . . . . . . . . . . . 31 4.9. DNS and LPWAN . . . . . . . . . . . . . . . . . . . . . . 31
5. Security Considerations . . . . . . . . . . . . . . . . . . . 31 5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
9. Informative References . . . . . . . . . . . . . . . . . . . 35 9. Informative References . . . . . . . . . . . . . . . . . . . 35
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 40 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 40
A.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 40 A.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 40
A.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 40 A.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 41
A.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 41 A.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 41
A.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 41 A.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 41
A.5. From -04 to -05 . . . . . . . . . . . . . . . . . . . . . 41 A.5. From -04 to -05 . . . . . . . . . . . . . . . . . . . . . 41
A.6. From -05 to -06 . . . . . . . . . . . . . . . . . . . . . 41 A.6. From -05 to -06 . . . . . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41 A.7. From -06 to -07 . . . . . . . . . . . . . . . . . . . . . 42
A.8. From -07 to -08 . . . . . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
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 very low-cost, low-throughput devices with very-low large numbers of very low-cost, low-throughput devices with very-low
power consumption, so that even battery-powered devices can be power consumption, so that even battery-powered devices can be
deployed for years. LPWAN devices also tend to be constrained in deployed for years. LPWAN devices also tend to be constrained in
their use of bandwidth, for example with limited frequencies being their use of bandwidth, for example with limited frequencies being
allowed to be used within limited duty-cycles (usually expressed as a allowed to be used within limited duty-cycles (usually expressed as a
percentage of time per-hour that the device is allowed to transmit.) percentage of time per-hour that the device is allowed to transmit.)
And as the name implies, coverage of large areas is also a common And as the name implies, coverage of large areas is also a common
goal. So, by and large, the different technologies aim for goal. So, by and large, the different technologies aim for
deployment in very similar circumstances. deployment in very similar circumstances.
What mainly distinguishes LPWANs from other constrained networks is
that in LPWANs the balancing act related to power consumption/battery
life, cost and bandwidth tends to prioritise doing better with
respect to power and cost and we are more willing to live with
extremely low bandwidth and constrained duty-cycles when making the
various trade-offs required, in order to get the multiple-kilometre
radio links implied by the "wide area" aspect of the LPWAN term.
Existing pilot deployments have shown huge potential and created much Existing pilot deployments have shown huge potential and created much
industrial interest in these technologies. As of today, essentially industrial interest in these technologies. As of today, essentially
no LPWAN devices have IP capabilities. Connecting LPWANs to the no LPWAN end-devices (other than for Wi-SUN) have IP capabilities.
Internet would provide significant benefits to these networks in Connecting LPWANs to the Internet would provide significant benefits
terms of interoperability, application deployment, and management, to these networks in terms of interoperability, application
among others. The goal of the IETF LPWAN working group is to, where deployment, and management, among others. The goal of the IETF LPWAN
necessary, adapt IETF-defined protocols, addressing schemes and working group is to, where necessary, adapt IETF-defined protocols,
naming to this particular constrained environment. addressing schemes and naming to this particular 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.
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.
Note that this text is not intended to be normative in any sense, but Note that this text is not intended to be normative in any sense, but
simply to help the reader in finding the relevant layer 2 simply to help the reader in finding the relevant layer 2
specifications and in understanding how those integrate with IETF- specifications and in understanding how those integrate with IETF-
defined technologies. Similarly, there is no attempt here to set out defined technologies. Similarly, there is no attempt here to set out
the pros and cons of the relevant technologies. the pros and cons of the relevant technologies.
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]
2.1.1. Provenance and Documents 2.1.1. Provenance and Documents
LoRaWAN is an ISM-based wireless technology for long-range low-power LoRaWAN is an ISM-based wireless technology for long-range low-power
low-data-rate applications developed by the LoRa Alliance, a low-data-rate applications developed by the LoRa Alliance, a
membership consortium. <https://www.lora-alliance.org/> This draft membership consortium. <https://www.lora-alliance.org/> This draft
is based on version 1.0.2 [LoRaSpec] of the LoRa specification. That is based on version 1.0.2 [LoRaSpec] of the LoRa specification. That
specification is publicly available and has already seen several specification is publicly available and has already seen several
deployments across the globe. deployments across the globe.
2.1.2. Characteristics 2.1.2. Characteristics
skipping to change at page 5, line 16 skipping to change at page 5, line 32
Communicates with gateways. Communicates with gateways.
o Gateway: a radio on the infrastructure-side, sometimes called a o Gateway: a radio on the infrastructure-side, sometimes called a
concentrator or base-station. Communicates with end-devices and, concentrator or base-station. Communicates with end-devices and,
via IP, with a network server. via IP, with a network server.
o Network Server: The Network Server (NS) terminates the LoRaWAN MAC o Network Server: The Network Server (NS) terminates the LoRaWAN MAC
layer for the end-devices connected to the network. It is the layer for the end-devices connected to the network. It is the
center of the star topology. center of the star topology.
o - Join Server: The Join Server (JS) is a server on the Internet o Join Server: The Join Server (JS) is a server on the Internet side
side of an NS that processes join requests from end-devices. of an NS that processes join requests from an end-devices.
o Uplink message: refers to communications from end-device to o Uplink message: refers to communications from an end-device to a
network server or application via one or more gateways. network server or application via one or more gateways.
o Downlink message: refers to communications from network server or o Downlink message: refers to communications from a network server
application via one gateway to a single end-device or a group of or application via one gateway to a single end-device or a group
end-devices (considering multicasting). of 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 In LoRaWAN networks, end-device transmissions may be received at
multiple gateways, so during nominal operation a network server may multiple gateways, so during nominal operation a network server may
see multiple instances of the same uplink message from an end-device. see multiple instances of the same uplink message from an end-device.
skipping to change at page 6, line 41 skipping to change at page 7, line 20
| Rx delay 2 | 2 s (must be RECEIVE_DELAY1 + 1s) | | Rx delay 2 | 2 s (must be RECEIVE_DELAY1 + 1s) |
| | | | | |
| join delay 1 | 5 s | | join delay 1 | 5 s |
| | | | | |
| join delay 2 | 6 s | | join delay 2 | 6 s |
| | | | | |
| 868MHz Default | 3 (868.1,868.2,868.3), data rate: 0.3-5 | | 868MHz Default | 3 (868.1,868.2,868.3), data rate: 0.3-5 |
| channels | kbps | | channels | kbps |
+------------------------+------------------------------------------+ +------------------------+------------------------------------------+
Table 1: Default settings for EU868MHz band Table 1: Default settings for EU 868MHz band
+-----------------------------------------------+--------+----------+ +-----------------------------------------------+--------+----------+
| Parameter/Notes | Min | Max | | Parameter/Notes | Min | Max |
+-----------------------------------------------+--------+----------+ +-----------------------------------------------+--------+----------+
| Duty Cycle: some but not all ISM bands impose | 1% | no-limit | | Duty Cycle: some but not all ISM bands impose | 1% | no-limit |
| a limit in terms of how often an end-device | | | | a limit in terms of how often an end-device | | |
| can transmit. In some cases LoRaWAN is more | | | | can transmit. In some cases LoRaWAN is more | | |
| restrictive in an attempt to avoid | | | | restrictive in an attempt to avoid | | |
| congestion. | | | | congestion. | | |
| | | | | | | |
skipping to change at page 10, line 35 skipping to change at page 11, line 7
messages. The Join-accept contains an AppNonce (a 24 bit value) that messages. The Join-accept contains an AppNonce (a 24 bit value) that
is recovered on the end-device along with the other Join-accept is recovered on the end-device along with the other Join-accept
content (e.g. DevAddr) using the AES-encrypt operation. Once the content (e.g. DevAddr) using the AES-encrypt operation. Once the
Join-accept payload is available to the end-device the session keys Join-accept payload is available to the end-device the session keys
are derived from the AppKey, AppNonce and other values, again using are derived from the AppKey, AppNonce and other values, again using
an ECB mode AES-encrypt operation, with the plaintext input being a an ECB mode AES-encrypt operation, with the plaintext input being a
maximum of 16 octets. maximum of 16 octets.
2.2. Narrowband IoT (NB-IoT) 2.2. Narrowband IoT (NB-IoT)
Text here is largely from [I-D.ratilainen-lpwan-nb-iot]
2.2.1. Provenance and Documents 2.2.1. Provenance and Documents
Narrowband Internet of Things (NB-IoT) is developed and standardized Narrowband Internet of Things (NB-IoT) is developed and standardized
by 3GPP. The standardization of NB-IoT was finalized with 3GPP by 3GPP. The standardization of NB-IoT was finalized with 3GPP
Release 13 in June 2016, and further enhancements for NB-IoT are Release 13 in June 2016, and further enhancements for NB-IoT are
specified in 3GPP Release 14 in 2017, for example in the form of specified in 3GPP Release 14 in 2017, for example in the form of
multicast support. Further features and improvements will be multicast support. Further features and improvements will be
developed in the following releases, but NB-IoT has been ready to be developed in the following releases, but NB-IoT has been ready to be
deployed since 2016, and is rather simple to deploy especially in the deployed since 2016, and is rather simple to deploy especially in the
existing LTE networks with a software upgrade in the operator's base existing LTE networks with a software upgrade in the operator's base
stations. For more information of what has been specified for NB- stations. For more information of what has been specified for NB-
IoT, 3GPP specification 36.300 [TGPP36300] provides an overview and IoT, 3GPP specification 36.300 [TGPP36300] provides an overview and
overall description of the E-UTRAN radio interface protocol overall description of the E-UTRAN radio interface protocol
architecture, while specifications 36.321 [TGPP36321], 36.322 architecture, while specifications 36.321 [TGPP36321], 36.322
[TGPP36322], 36.323 [TGPP36323] and 36.331 [TGPP36331] give more [TGPP36322], 36.323 [TGPP36323] and 36.331 [TGPP36331] give more
detailed description of MAC, RLC, PDCP and RRC protocol layers, detailed description of MAC, Radio Link Control (RLC), Packet Data
respectively. Note that the description below assumes familiarity Convergence Protocol (PDCP) and Radio Resource Control (RRC) protocol
with numerous 3GPP terms. layers, respectively. Note that the description below assumes
familiarity with numerous 3GPP terms.
For a general overview of NB-IoT, see [nbiot-ov].
2.2.2. Characteristics 2.2.2. Characteristics
Specific targets for NB-IoT include: Less than US$5 module cost, Specific targets for NB-IoT include: Less than US$5 module cost,
extended coverage of 164 dB maximum coupling loss, battery life of extended coverage of 164 dB maximum coupling loss, battery life of
over 10 years, ~55000 devices per cell and uplink reporting latency over 10 years, ~55000 devices per cell and uplink reporting latency
of less than 10 seconds. of less than 10 seconds.
NB-IoT supports Half Duplex FDD operation mode with 60 kbps peak rate NB-IoT supports Half Duplex FDD operation mode with 60 kbps peak rate
in uplink and 30 kbps peak rate in downlink, and a maximum in uplink and 30 kbps peak rate in downlink, and a maximum
skipping to change at page 15, line 8 skipping to change at page 15, line 33
SDUs, scheduling information reporting, error correction with HARQ, SDUs, scheduling information reporting, error correction with HARQ,
priority handling and transport format selection. priority handling and transport format selection.
Physical layer [TGPP36201] provides data transport services to higher Physical layer [TGPP36201] provides data transport services to higher
layers. These include error detection and indication to higher layers. These include error detection and indication to higher
layers, FEC encoding, HARQ soft-combining, rate matching and mapping layers, FEC encoding, HARQ soft-combining, rate matching and mapping
of the transport channels onto physical channels, power weighting and of the transport channels onto physical channels, power weighting and
modulation of physical channels, frequency and time synchronization modulation of physical channels, frequency and time synchronization
and radio characteristics measurements. and radio characteristics measurements.
User plane protocol stack
User plane is responsible for transferring the user data through the User plane is responsible for transferring the user data through the
Access Stratum. It interfaces with IP and the highest layer of user Access Stratum. It interfaces with IP and the highest layer of user
plane is PDCP, which in user plane performs header compression using plane is PDCP, which in user plane performs header compression using
Robust Header Compression (RoHC), transfer of user plane data between Robust Header Compression (RoHC), transfer of user plane data between
eNodeB and UE, ciphering and integrity protection. Similar to eNodeB and UE, ciphering and integrity protection. Similar to
control plane, lower layers in user plane include RLC, MAC and control plane, lower layers in user plane include RLC, MAC and
physical layer performing the same tasks as in control plane. physical layer performing the same tasks as in control plane.
2.3. SIGFOX 2.3. SIGFOX
Text here is largely from
[I-D.zuniga-lpwan-sigfox-system-description] which may have been
updated since this was published.
2.3.1. Provenance and Documents 2.3.1. Provenance and Documents
The SIGFOX LPWAN is in line with the terminology and specifications The SIGFOX LPWAN is in line with the terminology and specifications
being defined by ETSI [etsi_unb]. As of today, SIGFOX's network has being defined by ETSI [etsi_unb]. As of today, SIGFOX's network has
been fully deployed in 12 countries, with ongoing deployments on 26 been fully deployed in 12 countries, with ongoing deployments on 26
other countries, giving in total a geography of 2 million square other countries, giving in total a geography of 2 million square
kilometers, containing 512 million people. kilometers, containing 512 million people.
2.3.2. Characteristics 2.3.2. Characteristics
skipping to change at page 21, line 20 skipping to change at page 21, line 20
enterprise level security. The frequency hopping wireless mesh enterprise level security. The frequency hopping wireless mesh
topology aims to offer superior network robustness, reliability due topology aims to offer superior network robustness, reliability due
to high redundancy, good scalability due to the flexible mesh to high redundancy, good scalability due to the flexible mesh
configuration and good resilience to interference. Very low power configuration and good resilience to interference. Very low power
modes are in development permitting long term battery operation of modes are in development permitting long term battery operation of
network nodes. network nodes.
The following list contains some overall characteristics of Wi-SUN The following list contains some overall characteristics of Wi-SUN
that are relevant to LPWAN applications. that are relevant to LPWAN applications.
o Coverage The range of Wi-SUN FAN is typically 2 -- 3 km in line of o Coverage: The range of Wi-SUN FAN is typically 2 -- 3 km in line
sight, matching the needs of neighborhood area networks, campus of sight, matching the needs of neighborhood area networks, campus
area networks, or corporate area networks. The range can also be area networks, or corporate area networks. The range can also be
extended via multi-hop networking. extended via multi-hop networking.
o High bandwidth, low link latency: Wi-SUN supports relatively high o High bandwidth, low link latency: Wi-SUN supports relatively high
bandwidth, i.e. up to 300 kbps [FANTPS], enables remote update and bandwidth, i.e. up to 300 kbps [FANTPS], enables remote update and
upgrade of devices so that they can handle new applications, upgrade of devices so that they can handle new applications,
extending their working life. Wi-SUN supports LPWAN IoT extending their working life. Wi-SUN supports LPWAN IoT
applications that require on-demand control by providing low link applications that require on-demand control by providing low link
latency (0.02s) and bi-directional communication. latency (0.02s) and bi-directional communication.
skipping to change at page 26, line 4 skipping to change at page 25, line 48
Dev Radio Gateways NGW Dev Radio Gateways NGW
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. transmit for a certain percentage of each hour.
4. Gap Analysis 4. Gap Analysis
This section considers some of the gaps between current LPWAN
technologies and the goals of the LPWAN working group. Many of the
generic considerations described in [RFC7452] will also apply in
LPWANs, as end-devices can also be considered as a subclass of (so-
called) "smart objects." In addition, LPWAN device implementers will
also need to consider the issues relating to firmware updates
described in [RFC8240].
4.1. Naive application of IPv6 4.1. Naive application of IPv6
IPv6 [RFC2460] has been designed to allocate addresses to all the IPv6 [RFC8200] 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 could be needed just to carry the IP header. several LPWAN frames could be needed just to carry the IP header.
Another problem arises from IPv6 MTU requirements, which require the Another problem arises from IPv6 MTU requirements, which require the
layer below to support at least 1280 byte packets [RFC2460]. layer below to support at least 1280 byte packets [RFC2460].
IPv6 has a configuration protocol - neighbor discovery protocol, IPv6 has a configuration protocol - neighbor discovery protocol,
(NDP) [RFC4861]). For a node to learn network parameters NDP (NDP) [RFC4861]). For a node to learn network parameters NDP
generates regular traffic with a relatively large message size that generates regular traffic with a relatively large message size that
skipping to change at page 28, line 42 skipping to change at page 28, line 44
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 6LowPan Context Lifetime in the PIOs, and the Valid Lifetime in the 6LoWPAN Context
Option (6CO), as well as the address Registration Lifetime. However, Option (6CO), as well as the address Registration Lifetime. However,
for the latter LPWANs mentioned above, 6LoWPAN Neighbor Discovery is for the latter LPWANs mentioned above, 6LoWPAN Neighbor Discovery is
not suitable. 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
skipping to change at page 35, line 5 skipping to change at page 35, line 10
France France
Email: JuanCarlos.Zuniga@sigfox.com Email: JuanCarlos.Zuniga@sigfox.com
URI: http://www.sigfox.com/ URI: http://www.sigfox.com/
8. Acknowledgments 8. Acknowledgments
Thanks to all those listed in Section 7 for the excellent text. Thanks to all those listed in Section 7 for the excellent text.
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 Arun [[RFC editor: Please surnames below for I18N, at least Mirja's does
(arun@acklio.com), Dan Garcia Carrillo, Paul Duffy, Russ Housley, need fixing.]]
Thad Guidry, Jiazi Yi, for comments.
In addition to the contributors above, thanks are due to (in
alphabetical order): Abdussalam Baryun, Andy Malis, Arun
(arun@acklio.com), Behcet SariKaya, Dan Garcia Carrillo, Jiazi Yi,
Mirja Kuehlewind, Paul Duffy, Russ Housley, Thad Guidry, Warren
Kumari, for comments.
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
skipping to change at page 37, line 15 skipping to change at page 37, line 26
[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, <https://www.rfc- DOI 10.17487/RFC6961, June 2013, <https://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, <https://www.rfc- DOI 10.17487/RFC7252, June 2014, <https://www.rfc-
editor.org/info/rfc7252>. editor.org/info/rfc7252>.
[RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
"Architectural Considerations in Smart Object Networking",
RFC 7452, DOI 10.17487/RFC7452, March 2015,
<https://www.rfc-editor.org/info/rfc7452>.
[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,
<https://www.rfc-editor.org/info/rfc7668>. <https://www.rfc-editor.org/info/rfc7668>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, <https://www.rfc-
editor.org/info/rfc8200>.
[RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet
of Things Software Update (IoTSU) Workshop 2016",
RFC 8240, DOI 10.17487/RFC8240, September 2017,
<https://www.rfc-editor.org/info/rfc8240>.
[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
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-03 (work in draft-zuniga-lpwan-sigfox-system-description-04 (work in
progress), June 2017. progress), December 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.
skipping to change at page 39, line 23 skipping to change at page 39, line 45
"ARIB STD-T108 (Version 1.0): 920MHz-Band Telemeter, "ARIB STD-T108 (Version 1.0): 920MHz-Band Telemeter,
Telecontrol and data transmission radio equipment.", Telecontrol and data transmission radio equipment.",
February 2012. February 2012.
[LoRaSpec] [LoRaSpec]
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]
LoRa Alliance, "LoRaWAN Specification Version V1.0", Jan
2015, <https://www.lora-alliance.org/portals/0/specs/
LoRaWAN%20Specification%201R0.pdf>.
[ANSI-4957-000] [ANSI-4957-000]
ANSI, TIA-4957.000, "Architecture Overview for the Smart ANSI, TIA-4957.000, "Architecture Overview for the Smart
Utility Network", May 2013, <https://global.ihs.com/ Utility Network", May 2013, <https://global.ihs.com/
doc_detail.cfm?%26rid=TIA%26item_s_key=00606368>. doc_detail.cfm?%26rid=TIA%26item_s_key=00606368>.
[ANSI-4957-210] [ANSI-4957-210]
ANSI, TIA-4957.210, "Multi-Hop Delivery Specification of a ANSI, TIA-4957.210, "Multi-Hop Delivery Specification of a
Data Link Sub-Layer", May 2013, <https://global.ihs.com/ Data Link Sub-Layer", May 2013, <https://global.ihs.com/
doc_detail.cfm?%26csf=TIA%26item_s_key=00601800>. doc_detail.cfm?%26csf=TIA%26item_s_key=00601800>.
skipping to change at page 40, line 23 skipping to change at page 40, line 41
Protocol (KMP) Datagrams", IEEE Standard 802.15.9, 2016, Protocol (KMP) Datagrams", IEEE Standard 802.15.9, 2016,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
standard/802.15.9-2016.html>. standard/802.15.9-2016.html>.
[etsi_unb] [etsi_unb]
"ETSI TR 103 435 System Reference document (SRdoc); Short "ETSI TR 103 435 System Reference document (SRdoc); Short
Range Devices (SRD); Technical characteristics for Ultra Range Devices (SRD); Technical characteristics for Ultra
Narrow Band (UNB) SRDs operating in the UHF spectrum below Narrow Band (UNB) SRDs operating in the UHF spectrum below
1 GHz", February 2017. 1 GHz", February 2017.
[nbiot-ov]
Beyene, Yihenew Dagne, et al., "NB-IoT technology overview
and experience from cloud-RAN implementation", IEEE
Wireless Communications 24,3 (2017): 26-32, June 2017.
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)
skipping to change at page 41, line 37 skipping to change at page 42, line 13
o Handled Alper Yegin's WGLC review. o Handled Alper Yegin's WGLC review.
A.6. From -05 to -06 A.6. From -05 to -06
o More Alper comments:-) o More Alper comments:-)
o Added some more detail about sigfox security. o Added some more detail about sigfox security.
o Added Wi-SUN changes from Charlie Perkins o Added Wi-SUN changes from Charlie Perkins
Author's Address A.7. From -06 to -07
Yet more Alper comments:-)
Comments from Behcet Sarikaya
A.8. From -07 to -08
various typos
Last call and directorate comments from Abdussalam Baryun (AB) and
Andy Malis
20180118 IESG ballot comments from Warren: nits handled, two
possible bits of text still needed.
Some more AB comments handled. Still need to check over 7452 and
8240 to see if issues from those need to be discussed here.
Corrected "no IP capabilities - Wi-SUN devices do v6 (thanks Paul
Duffy:-)
Mirja's AD ballot comments handled.
Added a sentence in intro trying to say what's "special" about
LPWAN compared to other constrained networks. (As suggested by
Warren.)
Added text @ start of gap analysis referring to RFCs 7252 and
8240, as suggested by a few folks (AB, Warren, Mirja)
Added nbiot-ov reference for those who'd like a more polished
presentation of NB-IoT
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. 33 change blocks. 
54 lines changed or deleted 121 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/