draft-ietf-lpwan-overview-00.txt   draft-ietf-lpwan-overview-01.txt 
lpwan S. Farrell, Ed. lpwan S. Farrell, Ed.
Internet-Draft Trinity College Dublin Internet-Draft Trinity College Dublin
Intended status: Informational December 5, 2016 Intended status: Informational February 27, 2017
Expires: June 8, 2017 Expires: August 31, 2017
LPWAN Overview LPWAN Overview
draft-ietf-lpwan-overview-00 draft-ietf-lpwan-overview-01
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 June 8, 2017. This Internet-Draft will expire on August 31, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . 19
2.4.2. Characteristics . . . . . . . . . . . . . . . . . . . 20 2.4.2. Characteristics . . . . . . . . . . . . . . . . . . . 20
3. Generic Terminology . . . . . . . . . . . . . . . . . . . . . 22 3. Generic Terminology . . . . . . . . . . . . . . . . . . . . . 23
4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 23 4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Naive application of IPv6 . . . . . . . . . . . . . . . . 23 4.1. Naive application of IPv6 . . . . . . . . . . . . . . . . 24
4.2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1. Header Compression . . . . . . . . . . . . . . . . . 24 4.2.1. Header Compression . . . . . . . . . . . . . . . . . 25
4.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 25 4.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 26
4.2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 25 4.2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 26
4.2.4. Neighbor Discovery . . . . . . . . . . . . . . . . . 25 4.2.4. Neighbor Discovery . . . . . . . . . . . . . . . . . 27
4.3. 6lo . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3. 6lo . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4. 6tisch . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.4. 6tisch . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5. RoHC . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.5. RoHC . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6. ROLL . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.6. ROLL . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.7. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.7. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 28 4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 29
4.9. DNS and LPWAN . . . . . . . . . . . . . . . . . . . . . . 28 4.9. DNS and LPWAN . . . . . . . . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
9. Informative References . . . . . . . . . . . . . . . . . . . 32 9. Informative References . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 37
A.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37
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. Note that the eventual fate of this draft is a topic for the this.]]
WG to consider - it might end up as a useful RFC, or it might be best
maintained as a draft only until its utility has dissapated. FWIW,
the editor doesn't mind what outcome the WG choose.]]
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. And as the name implies, coverage devices can be deployed for years. LPWAN devices also tend to be
of large areas is also a common goal. So, by and large, the constrained in their use of bandwidth, for example with limited
different technologies aim for deployment in very similar frequencies being allowed to be used within limited duty-cycles
(usually expressed as a percentage of time/hour that the device is
allowed to transmit.) [[Ed: is that right?]] And as the name
implies, coverage of large areas is also a common goal. So, by and
large, the different 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, [[Ed: with
the possible exception of Wi-SUN devices?]] essentially no LPWAN the possible exception of Wi-SUN devices?]] essentially no LPWAN
devices have IP capabilities. Connecting LPWANs to the Internet devices have IP capabilities. Connecting LPWANs to the Internet
would provide significant benefits to these networks in terms of would provide significant benefits to these networks in terms of
interoperability, application deployment, and management, among interoperability, application deployment, and management, among
others. The goal of the LPWAN WG is to adapt IETF defined protocols, others. The goal of the LPWAN WG is to, where necessary, adapt IETF
addressing schemes and naming to this particular constrained defined protocols, addressing schemes and naming to this particular
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.
Note that this text is not intended to be normative in any sesne, but Note that this text is not intended to be normative in any sesne, 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. [[Ed: I assume the pros and cons of the relevant technologies.
that's the right target here. Please comment if you disagree.]]
[[Ed: the goal here is 2-3 pages per technology. If there's much
more needed then we could add appendices I guess depending on what
text the WG find useful to include.]]
[[Ed: A lot of the radio frequency related details below could
disappear I think - for the purposes of this WG, I think a lot of
that is extraneous detail. Haven't yet done that though, in case I'm
missing something. It might also further imbalance the level of
description of the different technologies, to the extent that the WG
care explicitly about that.]]
2.1. LoRaWAN 2.1. LoRaWAN
[[Ed: Text here is from [I-D.farrell-lpwan-lora-overview]]] Text here is largely from [I-D.farrell-lpwan-lora-overview] which may
have been updated since this was published.
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.2 version 1.0.2 [LoRaSpec] of the LoRa specification. Version 1.0,
is expected to be published in a few weeks. We will when that has which has also seen some deployment, is available at [LoRaSpec1.0].
happened. For now, version 1.0 is available at [LoRaSpec1.0])
2.1.2. Characteristics 2.1.2. Characteristics
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.
The LoRaWAN network infrastructure manages the data rate and RF The LoRaWAN network infrastructure manages the data rate and RF
output power for each end-device individually by means of an adaptive output power for each end-device individually by means of an adaptive
data rate (ADR) scheme. End-devices may transmit on any channel data rate (ADR) scheme. End-devices may transmit on any channel
skipping to change at page 5, line 45 skipping to change at page 5, line 45
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.
LoRaWAN radios make use of ISM bands, for example, 433MHz and 868MHz LoRaWAN radios make use of industrial, scientific and medical (ISM)
within the European Union and 915MHz in the Americas. bands, for example, 433MHz and 868MHz within the European Union and
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
from the end of the transmission window. End-devices can only from the end of the transmission window. End-devices can only
transmit a subsequent uplink frame after the end of the associated transmit a subsequent uplink frame after the end of the associated
receive windows. When a device joins a LoRaWAN network, there are receive windows. When a device joins a LoRaWAN network, there are
skipping to change at page 7, line 30 skipping to change at page 7, line 30
| | : 19 | 250 | | | : 19 | 250 |
| | octets | octets | | | octets | octets |
+-----------------------------------------------+--------+----------+ +-----------------------------------------------+--------+----------+
Table 2: Minima and Maxima for various LoRaWAN Parameters Table 2: Minima and Maxima for various LoRaWAN Parameters
Note that in the case of the smallest frame size (19 octets), 8 Note that in the case of the smallest frame size (19 octets), 8
octets are required for LoRa MAC layer headers leaving only 11 octets octets are required for LoRa MAC layer headers leaving only 11 octets
for payload (including MAC layer options). However, those settings for payload (including MAC layer options). However, those settings
do not apply for the join procedure - end-devices are required to use do not apply for the join procedure - end-devices are required to use
a channel that can send the 23 byte Join-request message for the join a channel and data rate that can send the 23 byte Join-request
procedure. message for the join procedure.
Uplink and downlink higher layer data is carried in a MACPayload. Uplink and downlink higher layer data is carried in a MACPayload.
There is a concept of "ports" (an optional 8 bit value) to handle There is a concept of "ports" (an optional 8 bit value) to handle
different applications on an end-device. Port zero is reserved for different applications on an end-device. Port zero is reserved for
LoRaWAN specific messaging, such as the join procedure. LoRaWAN specific messaging, such as the configuration of device's
network parameters (available channels, data rates, ADR parameters,
RX1/2 delay, etc.).
In addition to carrying higher layer PDUs there are Join-Request and In addition to carrying higher layer PDUs there are Join-Request and
Join-Response (aka Join-Accept) messages for handling network access. Join-Response (aka Join-Accept) messages for handling network access.
And so-called "MAC commands" (see below) up to 15 bytes long can be And so-called "MAC commands" (see below) up to 15 bytes long can be
piggybacked in an options field ("FOpts"). piggybacked in an options field ("FOpts").
There are a number of MAC commands for: Link and device status There are a number of MAC commands for: link and device status
checking, ADR and duty-cycle negotiation, managing the RX windows and checking, ADR and duty-cycle negotiation, managing the RX windows and
radio channel settings. For example, the link check response message radio channel settings. For example, the link check response message
allows the network server (in response to a request from an end- allows the network server (in response to a request from an end-
device) to inform an end-device about the signal attenuation seen device) to inform an end-device about the signal attenuation seen
most recently at a gateway, and to also tell the end-device how many most recently at a gateway, and to also tell the end-device how many
gateways received the corresponding link request MAC command. gateways received the corresponding link request MAC command.
Some MAC commands are initiated by the network server. For example, Some MAC commands are initiated by the network server. For example,
one command allows the network server to ask an end-device to reduce one command allows the network server to ask an end-device to reduce
it's duty-cycle to only use a proportion of the maximum allowed in a its duty-cycle to only use a proportion of the maximum allowed in a
region. Another allows the network server to query the end-device's region. Another allows the network server to query the end-device's
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 currently being enhanced within the LoRA Alliance, so "roaming" are defined in the upcoming LoRaWAN 1.1 specification.
the situation here is somewhat fluid.)
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
symmetric session keys, one for protecting network artefacts symmetric session keys, one for protecting network artefacts
(port=0), the NwkSKey, and another for protecting appliction layer (port=0), the NwkSKey, and another for protecting application layer
traffic, the AppSKey. Both keys are used for 128 bit AES traffic, the AppSKey. Both keys are used for 128 bit AES
cryptographic operations. So, one option is for an end-device to cryptographic operations. So, one option is for an end-device to
have all of the above, plus channel information, somehow have all of the above, plus channel information, somehow
(pre-)provisioned, in which case the end-device can simply start (pre-)provisioned, in which case the end-device can simply start
transmitting. This is achievable in many cases via out-of-band means transmitting. This is achievable in many cases via out-of-band means
given the nature of LoRaWAN networks. Table 3 summarises these given the nature of LoRaWAN networks. Table 3 summarises these
values. values.
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| Value | Description | | Value | Description |
skipping to change at page 9, line 12 skipping to change at page 9, line 27
Table 3: Values required for nominal operation Table 3: Values required for nominal operation
As an alternative, end-devices can use the LoRaWAN join procedure in As an alternative, end-devices can use the LoRaWAN join procedure in
order to setup some of these values and dynamically gain access to order to setup some of these values and dynamically gain access to
the network. To use the join procedure, an end-device must still the network. To use the join procedure, an end-device must still
know the AppEUI, and in addition, a different (long-term) symmetric know the AppEUI, and in addition, a different (long-term) symmetric
key that is bound to the AppEUI - this is the application key key that is bound to the AppEUI - this is the application key
(AppKey), and is distinct from the application session key (AppSKey). (AppKey), and is distinct from the application session key (AppSKey).
The AppKey is required to be specific to the device, that is, each The AppKey is required to be specific to the device, that is, each
end-device should have a different AppKey value. And finally the end-device should have a different AppKey value. And finally, the
end-device also needs a long-term identifier for itself, end-device also needs a long-term identifier for itself,
syntactically also an EUI-64, and known as the device EUI or DevEUI. syntactically also an EUI-64, and known as the device EUI or DevEUI.
Table 4 summarises these values. Table 4 summarises these values.
+---------+----------------------------------------------------+ +---------+----------------------------------------------------+
| Value | Description | | Value | Description |
+---------+----------------------------------------------------+ +---------+----------------------------------------------------+
| DevEUI | IEEE EUI64 naming the device | | DevEUI | IEEE EUI64 naming the device |
| | | | | |
| AppEUI | IEEE EUI64 naming the application | | AppEUI | IEEE EUI64 naming the application |
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)
[[Ed: Text here is from [I-D.ratilainen-lpwan-nb-iot].]] Text here is largely from [I-D.ratilainen-lpwan-nb-iot] which may
have been updated since this was published.
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, but further enhancements for NB-IoT are Release-13 in June 2016, but further enhancements for NB-IoT are
worked on in the following releases, for example in the form of worked on in the following releases, for example in the form of
multicast support. For more information of what has been specified multicast support. For more information of what has been specified
for NB-IoT, 3GPP specification 36.300 [TGPP36300] provides an for NB-IoT, 3GPP specification 36.300 [TGPP36300] provides an
overview and overall description of the E-UTRAN radio interface overview and overall description of the E-UTRAN radio interface
protocol architecture, while specifications 36.321 [TGPP36321], protocol architecture, while specifications 36.321 [TGPP36321],
36.322 [TGPP36322], 36.323 [TGPP36323] and 36.331 [TGPP36331] give 36.322 [TGPP36322], 36.323 [TGPP36323] and 36.331 [TGPP36331] give
more detailed description of MAC, RLC, PDCP and RRC protocol layers more detailed description of MAC, RLC, PDCP and RRC protocol layers
respectively. respectively. Note that the description below assumes familiarity
with numerous 3GPP terms.
2.2.2. Characteristics 2.2.2. Characteristics
[[Ed: Not clear what minimum/worst-case MTU might be. There are many [[Ed: Not clear what minimum/worst-case MTU might be.]]
3GPP acronyms/terms to eliminate or explain.]]
Specific targets for NB-IoT include: Less than 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 size MTU in uplink and 30 kbps peak rate in downlink, and a maximum size MTU
of 1600 bytes. As the name suggests, NB-IoT uses narrowbands with of 1600 bytes. As the name suggests, NB-IoT uses narrowbands with
the bandwidth of 180 kHz in both, downlink and uplink. The multiple the bandwidth of 180 kHz in both, downlink and uplink. The multiple
access scheme used in the downlink is OFDMA with 15 kHz sub-carrier access scheme used in the downlink is OFDMA with 15 kHz sub-carrier
spacing. On uplink multi-tone SC-FDMA is used with 15 kHz tone spacing. On uplink multi-tone SC-FDMA is used with 15 kHz tone
skipping to change at page 14, line 48 skipping to change at page 15, line 18
Under worst-case conditions, NB-IoT may achieve data rate of roughly Under worst-case conditions, NB-IoT may achieve data rate of roughly
200 bps. For downlink with 164 dB coupling loss, NB-IoT may achieve 200 bps. For downlink with 164 dB coupling loss, NB-IoT may achieve
higher data rates, depending on the deployment mode. Stand-alone higher data rates, depending on the deployment mode. Stand-alone
operation may achieve the highest data rates, up to few kbps, while operation may achieve the highest data rates, up to few kbps, while
in-band and guard-band operations may reach several hundreds of bps. in-band and guard-band operations may reach several hundreds of bps.
NB-IoT may even operate with higher maximum coupling loss than 170 dB NB-IoT may even operate with higher maximum coupling loss than 170 dB
with very low bit rates. with very low bit rates.
2.3. SIGFOX 2.3. SIGFOX
[[Ed: Text here is from Text here is largely from
[I-D.zuniga-lpwan-sigfox-system-description].]] [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 the ETSI ERM TG28 Low Throughput Networks (LTN) being defined by the ETSI ERM TG28 Low Throughput Networks (LTN)
group [etsi_ltn]. As of today, SIGFOX's network has been fully group [etsi_ltn]. As of today, SIGFOX's network has been fully
deployed in 6 countries, with ongoing deployments on 18 other deployed in 6 countries, with ongoing deployments on 18 other
countries, in total a geography containing 397M people. countries, in total a geography containing 397M people.
2.3.2. Characteristics 2.3.2. Characteristics
skipping to change at page 17, line 45 skipping to change at page 18, line 16
o Authentication: 16 bits o Authentication: 16 bits
o Frame check sequence: 8 bits (CRC) o Frame check sequence: 8 bits (CRC)
The radio interface is optimized for uplink transmissions, which are The radio interface is optimized for uplink transmissions, which are
asynchronous. Downlink communications are achieved by querying the asynchronous. Downlink communications are achieved by querying the
network for existing data from the device. network for existing data from the device.
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 network transmits duration of this window have fixed values. The LTN transmits the
the downlink message for a given device during the reception window. downlink message for a given device during the reception window. The
The LTN network selects the 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. These restrictions can be and 4 downlink messages per device. [[Ed: in what duration?]] These
slightly relaxed depending on system conditions and the specific restrictions can be slightly relaxed depending on system conditions
regulatory domain of operation. and the specific regulatory domain of operation.
+--+ +--+
|EP| * +------+ |EP| * +------+
+--+ * | RA | +--+ * | RA |
* +------+ * +------+
+--+ * | +--+ * |
|EP| * * * * | |EP| * * * * |
+--+ * +----+ | +--+ * +----+ |
* | BS | \ +--------+ * | BS | \ +--------+
+--+ * +----+ \ | | +--+ * +----+ \ | |
skipping to change at page 18, line 32 skipping to change at page 18, line 48
+--+ * / | | +--+ * / | |
* +----+ / +--------+ * +----+ / +--------+
+--+ * | BS |/ +--+ * | BS |/
|EP| * * * * +----+ |EP| * * * * +----+
+--+ * +--+ *
* *
+--+ * +--+ *
|EP| * * |EP| * *
+--+ +--+
Figure 7: ETSI LTN architecture Figure 7: SIGFOX architecture
Figure 7 depicts the different elements of the SIGFOX architecture. Figure 7 depicts the different elements of the SIGFOX architecture.
SIGFOX has a "one-contract one-network" model allowing devices to SIGFOX has a "one-contract one-network" model allowing devices to
connect in any country, without any notion of roaming. connect in any country, without any notion of roaming.
The architecture consists of a single core network, which allows The architecture consists of a single core network, which allows
global connectivity with minimal impact on the end device and radio global connectivity with minimal impact on the end device and radio
access network. The core network elements are the Service Center access network. The core network elements are the Service Center
(SC) and the Registration Authority (RA). The SC is in charge of the (SC) and the Registration Authority (RA). The SC is in charge of the
skipping to change at page 19, line 48 skipping to change at page 20, line 14
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 needed!]] is an IPv6 frequency The FAN profile [[Ed: reference (really really:-) needed!]] is an
hopping wireless mesh network with support for enterprise level IPv6 frequency hopping wireless mesh network with support for
security. The frequency hopping wireless mesh topology aims to offer enterprise level security. The frequency hopping wireless mesh
superior network robustness, reliability due to high redundancy, good topology aims to offer superior network robustness, reliability due
scalability due to the flexible mesh configuration and good to high redundancy, good scalability due to the flexible mesh
resilience to interference. Very low power modes are in development configuration and good resilience to interference. Very low power
permitting long term battery operation of network nodes. [[Ed: modes are in development permitting long term battery operation of
details welcome.]] 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 [[Ed: this really needs the references.]] The FAN profile is based on
various open standards in IETF, IEEE802 and ANSI/TIA for low power various open standards in IETF, IEEE802 and ANSI/TIA for low power
and lossy networks. The FAN profile specification provides an and lossy networks. The FAN profile specification provides an
application-independent IPv6-based transport service for both application-independent IPv6-based transport service for both
connectionless (i.e. UDP) and connection-oriented (i.e. TCP) connectionless (i.e. UDP) and connection-oriented (i.e. TCP)
services. There are two possible methods for establishing the IPv6 services. There are two possible methods for establishing the IPv6
packet routing: mandatory Routing Protocol for Low-Power and Lossy packet routing: mandatory Routing Protocol for Low-Power and Lossy
skipping to change at page 22, line 12 skipping to change at page 23, line 12
formats are based upon RFC5280. A secure group link between a Border formats are based upon RFC5280. A secure group link between a Border
Router and a set of FAN nodes is established using an adaptation of Router and a set of FAN nodes is established using an adaptation of
the IEEE802.11 Four-Way Handshake. A set of 4 group keys are the IEEE802.11 Four-Way Handshake. A set of 4 group keys are
maintained within the network, one of which is the current transmit maintained within the network, one of which is the current transmit
key. Secure node to node links are supported between one-hop FAN key. Secure node to node links are supported between one-hop FAN
neighbors using an adaptation of ETSI-TS-102-887-2. FAN nodes neighbors using an adaptation of ETSI-TS-102-887-2. FAN nodes
implement Frame Security as specified in IEEE802.15.4-2015. implement Frame Security as specified in IEEE802.15.4-2015.
3. Generic Terminology 3. Generic Terminology
[[Ed: Text here is from [I-D.minaburo-lpwan-gap-analysis].]]
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 The Host, which 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 hosts 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.
skipping to change at page 23, line 39 skipping to change at page 24, line 39
() () () | +------+ () () () | +------+
() () () () / \ +---------+ | AAA | () () () () / \ +---------+ | AAA |
() () () () () () / \========| /\ |====|Server| +-----------+ () () () () () () / \========| /\ |====|Server| +-----------+
() () () | | <--|--> | +------+ |Application| () () () | | <--|--> | +------+ |Application|
() () () () / \============| v |==============| Server | () () () () / \============| v |==============| Server |
() () () / \ +---------+ +-----------+ () () () / \ +---------+ +-----------+
HOSTS Radio Gateways Network Gateway HOSTS Radio Gateways Network Gateway
Figure 9: LPWAN Architecture Figure 9: LPWAN Architecture
4. Gap Analysis In addition to the names of entities, LPWANs are also subject to
possibly regional frequency band regulations. Those may include
restrictions on the duty-cycle, for example requiring that hosts only
transmit for a certain percentage of each hour. [[Ed: Are these
duty-cycle percentages always per-hour? Could a host amortise it's
transmits per day?]]
[[Ed: Text here is from [I-D.minaburo-lpwan-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.
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 needs a configuration protocol (neighbor discovery protocol, NDP IPv6 has a configuration protocol - neighbor discovery protocol,
[RFC4861]) for a node to learn network parameters NDP generates (NDP) [RFC4861]). For a node to learn network parameters NDP
regular traffic with a relatively large message size that does not generates regular traffic with a relatively large message size that
fit LPWAN constraints. does not fit LPWAN constraints.
In some LPWAN technologies, layer two multicast is not supported. In In some LPWAN technologies, layer two multicast is not supported. In
that case, if the network topology is a star, the solution and that case, if the network topology is a star, the solution and
considerations of section 3.2.5 of [RFC7668] may be applied. considerations of section 3.2.5 of [RFC7668] may be applied.
[[Ed: other things to maybe mention: IPsec, DHCPv6, anything with Other key protocols such as DHCPv6 [RFC3315], IPsec [RFC4301] and TLS
even 1 regular RTT needed, e.g. DNS.]] [RFC5246] have similarly problematic properties in this context.
Each of those require relatively frequent round-trips between the
host and some other host on the network. In the case of
cryptographic protocols such as IPsec and TLS, in addition to the
round-trips required for secure session establishment, cryptographic
operations can require padding and addition of authenticators that
are problematic when considering LPWAN lower layers.
4.2. 6LoWPAN 4.2. 6LoWPAN
Several technologies that exhibit significant constraints in various Several technologies that exhibit significant constraints in various
dimensions have exploited the 6LoWPAN suite of specifications dimensions have exploited the 6LoWPAN suite of specifications
[RFC4944], [RFC6282], [RFC6775] to support IPv6 [I-D.hong-6lo-use- [RFC4944], [RFC6282], [RFC6775] to support IPv6 [I-D.hong-6lo-use-
cases]. However, the constraints of LPWANs, often more extreme than cases]. However, the constraints of LPWANs, often more extreme than
those typical of technologies that have (re)used 6LoWPAN, constitute those typical of technologies that have (re)used 6LoWPAN, constitute
a challenge for the 6LoWPAN suite in order to enable IPv6 over LPWAN. a challenge for the 6LoWPAN suite in order to enable IPv6 over LPWAN.
LPWANs are characterised by device constraints (in terms of LPWANs are characterised by device constraints (in terms of
skipping to change at page 26, line 30 skipping to change at page 27, line 41
Neighbor Discovery behavior may be tuned through the use of Neighbor Discovery behavior may be tuned through the use of
appropriate values for the default Router Lifetime, the Valid appropriate values for the default Router Lifetime, the Valid
Lifetime in the PIOs, and the Valid Lifetime in the 6CO, as well as Lifetime in the PIOs, and the Valid Lifetime in the 6CO, as well as
the address Registration Lifetime. However, for the latter LPWANs the address Registration Lifetime. However, for the latter LPWANs
mentioned above, 6LoWPAN Neighbor Discovery is not suitable. mentioned above, 6LoWPAN Neighbor Discovery is not suitable.
4.3. 6lo 4.3. 6lo
The 6lo WG has been reusing and adapting 6LoWPAN to enable IPv6 The 6lo WG has been reusing and adapting 6LoWPAN to enable IPv6
support over link layer technologies such as Bluetooth Low Energy support over link layer technologies such as Bluetooth Low Energy
(BTLE), ITU-T G.9959, DECT-ULE, MS/TP-RS485, NFC or IEEE 802.11ah. (BTLE), ITU-T G.9959, DECT-ULE, MS/TP-RS485, NFC IEEE 802.11ah. (See
These technologies are similar in several aspects to IEEE 802.15.4, <https://tools.ietf.org/wg/6lo> for details.) These technologies are
which was the original 6LoWPAN target technology. [[Ed: refs?]] similar in several aspects to IEEE 802.15.4, which was the original
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. [[Ed: I'm not
sure that conclusion follows from the information provided in this sure that conclusion follows from the information provided in this
section - is more needed?.]] 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 TSCH [[Ed: 802.15.4e MAC with a deterministic slotted channel. The time slot
expand on 1st use]] can help to reduce collisions and to enable a channel (TSCH) can help to reduce collisions and to enable a better
better balance over the channels. It improves the battery life by balance over the channels. It improves the battery life by avoiding
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
determinism. TSCH and 6TiSCH may provide a standard scheduling determinism. TSCH and 6TiSCH may provide a standard scheduling
function. The LPWAN networks probably will not support function. The LPWAN networks probably will not support
synchronization like the one used in 6tisch. synchronization like the one used in 6tisch.
4.5. RoHC 4.5. RoHC
RoHC [[Ed: expand on 1st use]] header compression mechanisms were Robust header compression (RoHC) is a header compression mechanism
defined for point to point multimedia channels, to reduce the header [RFC3095] developed for multimedia flows in a point to point channel.
overhead of RTP flows. RoHC can also reduce the overhead of IPv4 or RoHC uses 3 levels of compression, each level having its own header
IPv6 or UDP headers. It is based on shared context which does not format. In the first level, RoHC sends 52 bytes of header, in the
require any state but compressed packets are not routable. The second level the header could be from 34 to 15 bytes and in the third
context is initialised at the beginning of the communication or when level header size could be from 7 to 2 bytes. The level of
it [[Ed: which "it"?]] is lost. The compression is managed using a compression is managed by a sequence number, which varies in size
sequence number (SN) which is encoded using a windowing algorithm from 2 bytes to 4 bits in the minimal compression. SN compression is
allowing for reduction of the SN to 4 bits instead of 2 bytes. [[Ed: done with an algorithm called W-LSB (Window- Least Signifiant Bits).
is that the 2 bytes as per 6lowPAN?]] But this window needs to be This window has a 4 bit size representing 15 packets, so every 15
updated each 15 packets which implies larger headers. When RoHC is packets RoHC needs to slide the window in order to receive the
used we talk about an average header compression size to give the correct sequence number, and sliding the window implies a reduction
performance of compression. For example, RoHC starts sending bigger of the level of compression. When packets are lost or errored, the
packets than the original (52 bytes) to reduce the header up to 4 decompressor loses context and drops packets until a bigger header is
bytes (it stays here only for 15 packets, which correspond to the sent with more complete information. To estimate the performance of
window size). Each time the context is lost or needs to be RoHC, an average header size is used. This average depends on the
synchronised, packets of about 15 to 43 bytes are sent. [[Ed: the transmission conditions, but most of the time is between 3 and 4
above isn't that cleaar to me.]] bytes.
RoHC is not adapted to the constrained nodes of the LPWAN networks: RoHC has not been adapted specifically to the constrained hosts and
it does not take into account the energy limitations and the networks of LPWANs: it does not take into account energy limitations
transmission rate, and context is synchronised during the nor the transmission rate, and RoHC context is synchronised during
transmission, which does not allow a better compression. [[Ed: this transmission, which does not allow better compression. [[Ed: this
seems to conflict a bit with what was said about 6tisch which puzzled seems to conflict a bit with what was said about 6tisch which puzzled
me.]] 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
skipping to change at page 28, line 25 skipping to change at page 29, line 41
4.8. Mobility 4.8. Mobility
LPWANs nodes can be mobile. However, LPWAN mobility is different LPWANs nodes can be mobile. However, LPWAN mobility is different
from the one specified for Mobile IP. LPWAN implies sporadic traffic from the one specified for Mobile IP. LPWAN implies sporadic traffic
and will rarely be used for high-frequency, real-time communications. and will rarely be used for high-frequency, real-time communications.
The applications do not generate a flow, they need to save energy and The applications do not generate a flow, they need to save energy and
most of the time the node will be down. 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 [[Ed: refs?]] Mobility solutions may be used in the case where NEMO [RFC3963] Mobility solutions may be used in the case where some
some hosts belonging to the same Network gateway will move from one hosts belonging to the same Network gateway will move from one point
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
The purpose of the DNS is to enable applications to name things that [[Ed: the WG probably need to decide what to say about DNS, there's
have a global unique name. Lots of protocols are using DNS to not much content here so far.]]
identify the objects, especially REST and applications using CoAP.
Therefore, hosts (things), or the named services they use, should be The Domain Name System (DNS) DNS [RFC1035], enables applications to
registered in DNS. DNS is probably a good topic of research for name things with a globallly resolvable name. Many protocols use the
LPWAN technologies, while the matching of the name and the IP DNS to identify hosts for example applications using CoAP.
information can be used to configure the LPWAN devices. [[Ed: I'm
not sure what that last bit means.]] 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
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
me anyway:-)]] whether and hw DNS-like functionality might be
provided in LPWANs.
5. Security Considerations 5. Security Considerations
[[Ed: be good to add stuff here about a) privacy and b) difficulties [[Ed: be good to add stuff here about a) privacy and b) difficulties
with getting current security protocols to work in this context. For with getting current security protocols to work in this context. For
a) maybe try find nice illustrations, e.g. extremecom instrumeted- a) maybe try find nice illustrations, e.g. extremecom instrumeted-
igloo traces (temperature change allowing one to infer when someone 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 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 in these environments. Not sure how much of that is known or useful
for the WG. Probably worth noting the IAB statement on for the WG. Probably worth noting the IAB statement on
skipping to change at page 32, line 18 skipping to change at page 33, line 33
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
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/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
D. Spence, "AAA Authorization Framework", RFC 2904, D. Spence, "AAA Authorization Framework", RFC 2904,
DOI 10.17487/RFC2904, August 2000, DOI 10.17487/RFC2904, August 2000,
<http://www.rfc-editor.org/info/rfc2904>. <http://www.rfc-editor.org/info/rfc2904>.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095,
July 2001, <http://www.rfc-editor.org/info/rfc3095>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, DOI 10.17487/RFC3963, January 2005,
<http://www.rfc-editor.org/info/rfc3963>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[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>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[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>.
skipping to change at page 35, line 6 skipping to change at page 37, line 11
Range Devices (SRD); Radio equipment to be used in the 25 Range Devices (SRD); Radio equipment to be used in the 25
MHz to 1 000 MHz frequency range with power levels ranging MHz to 1 000 MHz frequency range with power levels ranging
up to 500 mW", May 2016. up to 500 mW", May 2016.
[arib_ref] [arib_ref]
"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", Nov LoRa Alliance, "LoRaWAN Specification Version V1.0.2",
2016, <URL TBD>. July 2016, <http://portal.lora-
alliance.org/DesktopModules/Inventures_Document/
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>.
Appendix A. Changes
A.1. From -00 to -01
o WG have stated they want this to be an RFC.
o WG clearly want to keep the RF details.
o Various changes made to remove/resolve a number of editorial notes
from -00 (in some cases as per suggestions from Ana Minaburo)
o Merged PR's: #1...
o Github repo is at: https://github.com/sftcd/lpwan-ov
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. 46 change blocks. 
141 lines changed or deleted 199 lines changed or added

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