Internet DRAFT - draft-minaburo-lpwan-gap-analysis
draft-minaburo-lpwan-gap-analysis
Network Working Group A. Minaburo, Ed.
Internet-Draft Acklio
Intended status: Informational C. Gomez, Ed.
Expires: April 22, 2017 UPC/i2CAT
L. Toutain
Institut MINES TELECOM ; TELECOM Bretagne
J. Paradells
UPC/i2CAT
J. Crowcroft
University of Cambridge
October 19, 2016
LPWAN Survey and GAP Analysis
draft-minaburo-lpwan-gap-analysis-02
Abstract
Low Power Wide Area Networks (LPWAN) are technologies covering
different applications based on long range, low bandwidth and low
power operation. The use of IETF protocols in the LPWAN technologies
should contribute to the deployment of a wide number of applications
in an open and standard environment where actual devices using LPWAN
technologies will be able to communicate. This document makes a
survey of the principal characteristics of these technologies and
provides the gaps for the integration on the IETF protocol stack.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2017.
Minaburo, et al. Expires April 22, 2017 [Page 1]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Benchmark change . . . . . . . . . . . . . . . . . . . . 4
2.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 5
3. Analysis of gaps in current IETF protocols concerning LPWANs 6
3.1. IPv6 and LPWAN . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Unicast and Multicast mapping . . . . . . . . . . . . 7
3.2. 6LoWPAN and LPWAN . . . . . . . . . . . . . . . . . . . . 7
3.2.1. 6LoWPAN Header Compression . . . . . . . . . . . . . 7
3.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 8
3.2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 8
3.2.4. Neighbor Discovery . . . . . . . . . . . . . . . . . 9
3.3. 6lo and LPWAN . . . . . . . . . . . . . . . . . . . . . . 9
3.4. 6tisch and LPWAN . . . . . . . . . . . . . . . . . . . . 10
3.5. RoHC and LPWAN . . . . . . . . . . . . . . . . . . . . . 10
3.6. ROLL and LPWAN . . . . . . . . . . . . . . . . . . . . . 10
3.7. CoRE and LPWAN . . . . . . . . . . . . . . . . . . . . . 11
3.8. Security and LPWAN . . . . . . . . . . . . . . . . . . . 11
3.9. Mobility and LPWAN . . . . . . . . . . . . . . . . . . . 11
3.9.1. NEMO and LPWAN . . . . . . . . . . . . . . . . . . . 12
3.10. DNS and LPWAN . . . . . . . . . . . . . . . . . . . . . . 12
4. Annex A -- survey of LPWAN technologies . . . . . . . . . . . 12
5. Annex B -- Security in LPWAN technologies . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
7. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Minaburo, et al. Expires April 22, 2017 [Page 2]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
1. Introduction
LPWAN (Low-Power Wide Area Network) technologies define long range,
low bit rate and low power wireless interfaces that are a kind of
constrained and challenged networks [RFC7228]. They can operate in
license or license-exempt bands to provide connectivity to a vast
number of battery-powered devices requiring limited communications.
If the existing pilot deployments have shown the huge potential and
the industrial interest in their capabilities, the loose coupling
with the Internet makes the device management and network operation
complex. More importantly, LPWAN devices are, as of today, with no
IP capabilities.
Connecting LPWANs to the Internet would provide significant benefits
to these networks in terms of interoperability, application
deployment, and management, among others. The goal is to adapt IETF
defined protocols, addressing schemes and naming spaces to this
constrained environment. This document surveys the main
characteristics of LPWAN technologies, and analyzes the gaps for the
integration of the IETF protocol stack in the LPWAN technologies.
2. Problem Statement
The LPWANs are large-scale constrained networks in the sense of
[RFC7228] with the following characteristics:
o very small frame payload as low as 8 bytes. Typical traffic
patterns are composed of a large majority of frames with payload
size around 15 bytes and a small minority of up to 100 byte
frames.
o very low bandwidth, most LPWAN technologies offer a throughput
between 50 bit/s to 250 kbit/s.
o in some technologies, very limited message rate (e.g. between ~0.1
message/minute and ~1 message/minute) due to regional regulations
that limit the duty cycle (e.g. from 0.1% to 10%) in some ISM
bands. Some nodes will exchange less than 10 frames per day.
o high packet loss rate, which can be the result of bad transmission
conditions between nodes.
o variable MTU for a link depending on the used L2 modulation.
o in some cases, lack of L2 fragmentation capabilities.
o highly asymmetric and in some cases unidirectional links.
Minaburo, et al. Expires April 22, 2017 [Page 3]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
o ultra dense networks with thousands to tens of thousands of nodes.
o typically, star topology networks.
o different modulations and radio channels within the same
technology.
o sleepy nodes to preserve energy.
In the terminology of [RFC7228], these characteristics put LP-WANs
into the "challenged network" category where the IP connectivity has
to be redefined or modified. Therefore, LPWANs need to be considered
as a separate class of networks with the following desired
properties:
o keep compatibility with current Internet:
* preserve the end-to-end communication principle.
* maintain independence from L2 technology.
* use or adapt protocols defined by IETF to this new environment
that could be less responsive.
* use existing addressing spaces and naming schemes defined by
IETF.
o ensure the correspondence with the stringent LPWAN requirements,
such as:
* limited number of messages per time unit per device.
* small message size, with potentially no L2 fragmentation.
* RTTs potentially orders of magnitude bigger than in existing
constrained networks.
o optimize the protocol stack in order to limit the number of
duplicated functionalities; for instance acknowledgements should
not be generated at several layers.
2.1. Benchmark change
The data transmission rate (DTR) is the amount of digital data that
is moved from one device to another in a given time. In a network,
the DTR can be viewed as the speed of travel of a given amount of
data. The greater the bandwidth of a path the higher the DTR
Minaburo, et al. Expires April 22, 2017 [Page 4]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
(usually measured in bit per second, bit/s). For example, a low-
speed connection to the Internet may have a DTR of 33.6 kilobit/s.
LPWAN DTR is lower than 1 byte/s in the most constrained links. So
standard marks need to be adjusted, like for instance, instead of
sending data per second we are sending the data per day. Which
implies that many of the actual protocols need to be adapted to this
new scale.
Timers, delays, RTTs, buffers, etc. will need to make a time shift in
order to correctly perform over an LPWAN link. A concrete example
could be the CoAP timers that need to be tuned properly.
2.2. Architecture
LPWAN technologies, such as LoRaWAN, NB-IOT and SIGFOX, have similar
architectures but different terminology. We can identify different
types of entities in a typical LPWAN network:
o The Host, which are the devices or the things (e.g. sensors,
actuators, etc.), they are named differently in each technology
(End Device, User Equipment or End Point). There is a high
density of hosts per radio gateway.
o The Radio Gateway, which is the end point of the constrained link.
It is known as: Gateway, Evolved Node B or Base station.
o The Network Gateway or Router is the interconnection node between
the Radio Gateway and the Internet. It is known as: Network
Server, Serving GW or Service Center.
o AAA Server, which controls the user authentication, the
applications. It is known as: Join-Server, Home Subscriber Server
or Registration Authority.
o At last we have the Application Server, known also as Packet Data
Node Gateway or Network Application.
Minaburo, et al. Expires April 22, 2017 [Page 5]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
+---------------------------------------------------------------------+
| Function/ | | | | |
| Technology | LORAWAN | NB-IOT | SIGFOX | IETF |
+--------------+-----------+------------+-------------+---------------+
| Sensor, | | | | |
| Actuator, | End | User | End | Thing |
|device, object| Device | Equipment | Point | (HOST) |
+--------------+-----------+------------+-------------+---------------+
| Transceiver | | Evolved | Base | RADIO |
| Antenna | Gateway | Node B | Station | GATEWAY |
+--------------+-----------+------------+-------------+---------------+
| Server | Network | Serving- | Service |Network Gateway|
| | Server | Gateway | Center | (ROUTER) |
+--------------+-----------+------------+-------------+---------------+
| Security | Join | Home |Registration | |
| Server | Server | Subscriber | Authority | AAA |
| | | Server | | SERVER |
+--------------+-----------+------------+-------------+---------------+
| Application |Application| Packet Data| Network | APPLICATION |
| | Server |Node Gateway| Application | SERVER |
+---------------------------------------------------------------------+
LPWAN Architecture Terminology
Figure 1
() () () | +------+
() () () () / \ +---------+ | AAA |
() () () () () () / \========| /\ |====|Server| +-----------+
() () () | | <--|--> | +------+ |Application|
() () () () / \============| v |==============| Server |
() () () / \ +---------+ +-----------+
HOSTS Radio Gateways Network Gateway
LPWAN Architecture
Figure 2
3. Analysis of gaps in current IETF protocols concerning LPWANs
3.1. IPv6 and LPWAN
IPv6 [RFC2460] has been designed to allocate addresses to all the
nodes connected to the Internet. Nevertheless, the header overhead
of, at least, 40 bytes introduced by the protocol is incompatible
with the LPWAN constraints. If IPv6 (with no further optimization)
Minaburo, et al. Expires April 22, 2017 [Page 6]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
were used, several LPWAN frames would be needed just to carry the
header, discussion on this point is developed in the 6LoWPAN section
below. Another limitation comes from the IPv6 MTU requirement, by
which the layer below IP has to support packets of at least 1280
bytes [RFC2460].
IPv6 needs a configuration protocol (neighbor discovery protocol, NDP
[RFC4861]) for a node to learn network parameters, and the node
relation with its neighbours. This protocol generates a regular
traffic with a large message size that does not fit LPWAN
constraints.
3.1.1. Unicast and Multicast mapping
In some LPWAN technologies, layer two multicast is not supported. In
that case, if the network topology is a star, the solution and
considerations of section 3.2.5 of [RFC7668] may be applied.
3.2. 6LoWPAN and LPWAN
Several technologies that exhibit significant constraints in various
dimensions have exploited the 6LoWPAN suite of specifications
[RFC4944], [RFC6282], [RFC6775] to support IPv6 [I-D.hong-6lo-use-
cases]. However, the constraints of LPWANs, often more extreme than
those typical of technologies that have (re)used 6LoWPAN, constitute
a challenge for the 6LoWPAN suite in order to enable IPv6 over LPWAN.
LPWANs are characterised by device constraints (in terms of
processing capacity, memory, and energy availability), and specially,
link constraints, such as:
o very low layer two payload size (from ~10 to ~100 bytes),
o very low bit rate (from ~10 bit/s to ~100 kbit/s), and
o in some specific technologies, further message rate constraints
(e.g. between ~0.1 message/minute and ~1 message/minute) due to
regional regulations that limit the duty cycle.
3.2.1. 6LoWPAN Header Compression
6LoWPAN header compression reduces IPv6 (and UDP) header overhead by
eliding header fields when they can be derived from the link layer,
and by assuming that some of the header fields will frequently carry
expected values. 6LoWPAN provides both stateless and stateful header
compression. In the latter, all nodes of a 6LoWPAN are assumed to
share compression context. In the best case, the IPv6 header for
link-local communication can be reduced to only 2 bytes. For global
communication, the IPv6 header may be compressed down to 3 bytes in
Minaburo, et al. Expires April 22, 2017 [Page 7]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
the most extreme case. However, in more practical situations, the
lowest IPv6 header size may be 11 bytes (one address prefix
compressed) or 19 bytes (both source and destination prefixes
compressed). These headers are large considering the link layer
payload size of LPWAN technologies, and in some cases are even bigger
than the LPWAN PDUs. 6LoWPAN has been initially designed for IEEE
802.15.4 networks with a frame size up to 127 bytes and a throughput
of up to 250 kb/s, which may or may not be duty-cycled.
3.2.2. Address Autoconfiguration
In the ambit of 6LoWPAN, traditionally, Interface Identifiers (IIDs)
have been derived from link layer identifiers [RFC4944] . This allows
optimisations such as header compression. Nevertheless, recent
guidance has given advice on the fact that, due to privacy concerns,
6LoWPAN devices should not be configured to embed their link layer
addresses in the IID by default.
3.2.3. Fragmentation
As stated above, IPv6 requires the layer below to support an MTU of
1280 bytes [RFC2460]. Therefore, given the low maximum payload size
of LPWAN technologies, fragmentation is needed.
If a layer of an LPWAN technology supports fragmentation, proper
analysis has to be carried out to decide whether the fragmentation
functionality provided by the lower layer or fragmentation at the
adaptation layer should be used. Otherwise, fragmentation
functionality shall be used at the adaptation layer.
6LoWPAN defined a fragmentation mechanism and a fragmentation header
to support the transmission of IPv6 packets over IEEE 802.15.4
networks [RFC4944]. While the 6LoWPAN fragmentation header is
appropriate for IEEE 802.15.4-2003 (which has a frame payload size of
81-102 bytes), it is not suitable for several LPWAN technologies,
many of which have a maximum payload size that is one order of
magnitude below that of IEEE 802.15.4-2003. The overhead of the
6LoWPAN fragmentation header is high, considering the reduced payload
size of LPWAN technologies and the limited energy availability of the
devices using such technologies. Furthermore, its datagram offset
field is expressed in increments of eight octets. In some LPWAN
technologies, the 6LoWPAN fragmentation header plus eight octets from
the original datagram exceeds the available space in the layer two
payload. In addition, the MTU in the LPWAN networks could be
variable which implies a variable fragmentation solution.
Minaburo, et al. Expires April 22, 2017 [Page 8]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
3.2.4. Neighbor Discovery
6LoWPAN Neighbor Discovery [RFC6775] defined optimizations to IPv6
Neighbor Discovery [RFC4861], in order to adapt functionality of the
latter for networks of devices using IEEE 802.15.4 or similar
technologies. The optimizations comprise host-initiated interactions
to allow for sleeping hosts, replacement of multicast-based address
resolution for hosts by an address registration mechanism, multihop
extensions for prefix distribution and duplicate address detection
(note that these are not needed in a star topology network), and
support for 6LoWPAN header compression.
6LoWPAN Neighbor Discovery may be used in not so severely constrained
LPWAN networks. The relative overhead incurred will depend on the
LPWAN technology used (and on its configuration, if appropriate). In
certain LPWAN setups (with a maximum payload size above ~60 bytes,
and duty-cycle-free or equivalent operation), an RS/RA/NS/NA exchange
may be completed in a few seconds, without incurring packet
fragmentation. 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 hours or even days, leading to severe fragmentation and
consuming a significant amount of the available network resources.
6LoWPAN Neighbor Discovery behavior may be tuned through the use of
appropriate values for the default Router Lifetime, the Valid
Lifetime in the PIOs, and the Valid Lifetime in the 6CO, as well as
the address Registration Lifetime. However, for the latter LPWANs
mentioned above, 6LoWPAN Neighbor Discovery is not suitable.
3.3. 6lo and LPWAN
The 6lo WG has been reusing and adapting 6LoWPAN to enable IPv6
support over a variety of constrained node link layer technologies
such as Bluetooth Low Energy (BLE), ITU-T G.9959, DECT-ULE, MS/TP-
RS485, NFC or IEEE 802.11ah.
These technologies are relatively similar in several aspects to IEEE
802.15.4, which was the original 6LoWPAN target technology. 6LoWPAN
has been the basis for the functionality defined by 6Lo, which has
mostly used the subset of 6LoWPAN techniques most suitable for each
lower layer technology, and has provided additional optimizations for
technologies where the star topology is used, such as BLE or DECT-
ULE.
The main constraint in these networks comes from the nature of the
devices (constrained devices), whereas in LPWANs it is the network
itself that imposes the most stringent constraints.
Minaburo, et al. Expires April 22, 2017 [Page 9]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
3.4. 6tisch and LPWAN
The 6tisch solution is dedicated to mesh networks that operate using
802.15.4e MAC with a deterministic slotted channel. The TSCH can
help to reduce collisions and to enable a better balance over the
channels. It improves the battery life by avoiding the idle
listening time for the return channel.
A key element of 6tisch is the use of synchronization to enable
determinism. TSCH and 6TiSCH may provide a standard scheduling
function. The LPWAN networks probably will not support
synchronization like the one used in 6tisch.
3.5. RoHC and LPWAN
RoHC header compression mechanisms were defined for point to point
multimedia channels, to reduce the header overhead of the RTP flows,
it can also reduce the overhead of IPv4 or IPv6 or IPv4/v6/UDP
headers. It is based on a shared context which does not require any
state but packets are not routable. The context is initialised at
the beginning of the communication or when it is lost. The
compression is managed using a sequence number (SN) which is encoded
using a window algorithm letting the reduction of the SN to 4 bits
instead of 2 bytes. But this window needs to be updated each 15
packets which implies larger headers. When RoHC compression is used
we talk about an average header compression size to give the
performance of compression. For example, the compression start
sending bigger packets than the original (52 bytes) to reduce the
header up to 4 bytes (it stays here only for 15 packets, which
correspond to the window size). Each time the context is lost or
needs to be synchronised, packets of about 15 to 43 bytes are sent.
The RoHC header compression is not adapted to the constrained nodes
of the LPWAN networks: it does not take into account the energy
limitations and the transmission rate, and context is synchronised
during the transmission, which does not allow a better compression.
3.6. ROLL and LPWAN
The LPWAN technologies considered by the lpwan WG are based on a star
topology, which eliminates the need for routing. Future works may
address additional use-cases which may require the adaptation of
existing routing protocols or the definition of new ones. As of the
writing, the work done at the ROLL WG and other routing protocols are
out of scope of the LPWAN WG.
Minaburo, et al. Expires April 22, 2017 [Page 10]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
3.7. CoRE and LPWAN
CoRE provides a resource-oriented framework for applications intended
to run on constrained IP networks. It may be necessary to adapt the
protocols to take into account the duty cycling and the potentially
extremely limited throughput of LPWANs.
For example, some of the timers in CoAP may need to be redefined.
Taking into account CoAP acknowledgements may allow the reduction of
L2 acknowledgements. On the other hand, the current work in progress
in the CoRE WG where the COMI/CoOL network management interface
which, uses Structured Identifiers (SID) to reduce payload size over
CoAP proves to be a good solution for the LPWAN technologies. The
overhead is reduced by adding a dictionary which matches a URI to a
small identifier and a compact mapping of the YANG model into the
CBOR binary representation.
3.8. Security and LPWAN
Most of the LPWAN technologies integrate some authentication or
encryption mechanisms (see Section 5) that may not have been defined
by the IETF. The working group will work to integrate these
mechanisms to unify management. For the technologies which are not
integrating natively security protocols, it is necessary to adapt
existing mechanisms to the LPWAN constraints. The AAA infrastructure
brings a scalable solution. It offers a central management for the
security processes, draft-garcia- dime-diameter-lorawan-00 and draft-
garcia-radext-radius-lorawan-00 explain the possible security process
for a LoRaWAN network. The mechanisms basically are divided in: key
management protocols, encryption and integrity algorithms used. Most
of the solutions do not present a key management procedure to derive
specific keys for securing network and or data information. In most
cases, a pre-shared key between the smart object and the
communication endpoint is assumed.
3.9. Mobility and LPWAN
LPWANs nodes can be mobile. However, LPWAN mobility is different
from the one specified for Mobile IP. LPWAN implies sporadic traffic
and will rarely be used for high-frequency, real-time communications.
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
of the time a group of devices, which represent a network itself.
The mobility concerns more the gateway than the devices.
Minaburo, et al. Expires April 22, 2017 [Page 11]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
3.9.1. NEMO and LPWAN
NEMO Mobility solutions may be used in the case where some hosts
belonging to the same Network gateway will move from one point to
another and that they are not aware of this mobility.
3.10. DNS and LPWAN
The purpose of the DNS is to enable applications to name things that
have a global unique name. Lots of protocols are using DNS to
identify the objects, especially REST and applications using CoAP.
Therefore, things should be registered in DNS. DNS is probably a
good topic of research for LPWAN technologies, while the matching of
the name and the IP information can be used to configure the LPWAN
devices.
4. Annex A -- survey of LPWAN technologies
Different technologies can be included under the LPWAN acronym. The
following list is the result of a survey among the first participant
to the mailing-list. It cannot be exhaustive but is representative
of the current trends.
Minaburo, et al. Expires April 22, 2017 [Page 12]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
+-------------+---------------+--------------+--------+
|Technology |range | Throughput |MAC MTU |
+-------------+---------------+--------------+--------+
|LoRa |2-5 km urban |0.3 to 50 kbps|256 B |
| |<15 km suburban| | |
+-------------+---------------+--------------+--------+
|SIGFOX |10 km urban |up:100/600 bps| 12/ |
| |50 km rural |down: 600 bps | 8 B |
+-------------+---------------+--------------+--------+
|IEEE802.15.4k| < 20 km LoS |1.5 bps to |16/24/ |
|LECIM | < 5 km NoLoS | 128 kbps | 32 B |
+-------------+---------------+--------------+--------+
|IEEE802.15.4g| 2-3 km LoS | 4.8 kbps to |2047 B |
|SUN | |800 kbps | |
+-------------+---------------+--------------+--------+
|RPMA | 65 km LoS | up: 624kbps |64 B |
| | 20 km NoLoS |down: 156kbps | |
| | | mob: 2kbps | |
+-------------+---------------+--------------+--------+
|DASH-7 | 2 km | 9 kbps |256 B |
| | | 55.55 kbps | |
| | | 166.66 kbps | |
+-------------+---------------+--------------+--------+
|Weightless-w | 5 km urban | 1 kbps to |min 10 B|
| | | 10 Mbps | |
+-------------+---------------+--------------+--------+
|Weightless-n |<5 km urban | 30 kbps to |max 20 B|
| |<30 km suburban| 100kbps | |
+-------------+---------------+--------------+--------+
|Weightless-p |> 2 km urban | up to 100kbps| |
+-------------+---------------+--------------+--------+
| NB-IoT * | <15 km | ~ 200kbps | >1000B |
+-------------+---------------+--------------+--------+
* supports segmentation
Figure 3: Survey of LPWAN technologies
The table Figure 3 gives some key performance parameters for some
candidate technologies. The maximum MTU size must be taken
carefully, for instance in LoRa, it take up to 2 sec to send a 50
Byte frame using the most robust modulation. In that case the
theoretical limit of 256 B will be impossible to reach.
Most of the technologies listed in the Annex A work in the ISM band
and may be used for private a public networks. Weightless-W uses
white spaces in the TV spectrum and NB-LTE will use licensed
channels. Some technologies include encryption at layer 2.
Minaburo, et al. Expires April 22, 2017 [Page 13]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
5. Annex B -- Security in LPWAN technologies
LORAWAN
LoRaWAN provides a joining procedure called "Over the Air Activation"
that enables a smart object to securely join the network, deriving
the necessary keys to perform the communications securely. The
messages are integrity protected and the application information is
ciphered with the derived keys from the joining procedure.
The joining procedure consists of one exchange, that entails a join-
request message and a join-accept message. Upon successful
authentication, the smart- object and the network-server are able to
derive two keys to secure the communications (AppSKey and NwkSKey)
SIGFOX
The SIGFOX radio protocol provides mechanisms to authenticate and
ensure integrity of the message. This is achieved by using a unique
device ID and a message authentication code, which allow ensuring
that the message has been generated and sent by the device with the
ID claimed in the message.
Security keys are independent for each device. These keys are
associated with the device ID and they are pre-provisioned.
Application data can be encrypted by the application provider.
IEEE802.15.4k and IEEE802.15.4g
There is no mention of acquiring key material to secure the
communications.
DASH-7
DASH-7 defines 2 keys for specific users (root, user) and a network
key. Provides network security, integrity and encryption. The
process of how these keys are distributed is not explained.
RPMA
They use security algorithms and provides for mutual device
authentication, message authentication and message confidentiality.
No mention of how the key material is distributed.
Weightless
They offer a joining procedure to network by authenticating the smart
object. Integrity of the messages, encryption and key distribution
Minaburo, et al. Expires April 22, 2017 [Page 14]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
NB-IoT
ToDo. Not Access to the specification.
6. Acknowledgements
Thanks you very much for the discussion and feedback on the LPWAN
mailing list, namely, Alexander Pelov, Pascal Thubert, Samita
Chakrabarti, Xavier Vilajosana, Misha Dohler, Florian Meier, Timothy
J. Salo, Michael Richardson, Robert Cragie, Paul Duffy, Pat Kinney,
Joaquin Cabezas and Bill Gage.
We would like also to thank Dan Garcia Carrillo and Rafael Marin
Lopez for the input made for the security part.
Carles Gomez has been funded in part by the Spanish Government
(Ministerio de Educacion, Cultura y Deporte) through the Jose
Castillejo grant CAS15/00336. Part of his contribution to this work
has been carried out during his stay as a visiting scholar at the
Computer Laboratory of the University of Cambridge.
7. Normative References
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
Minaburo, et al. Expires April 22, 2017 [Page 15]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<http://www.rfc-editor.org/info/rfc7668>.
Authors' Addresses
Ana Minaburo (editor)
Acklio
2bis rue de la Chataigneraie
35510 Cesson-Sevigne Cedex
France
Email: ana@ackl.io
Carles Gomez (editor)
UPC/i2CAT
C/Esteve Terradas, 7
Castelldefels 08860
Spain
Email: carlesgo@entel.upc.edu
Laurent Toutain
Institut MINES TELECOM ; TELECOM Bretagne
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
Email: Laurent.Toutain@telecom-bretagne.eu
Minaburo, et al. Expires April 22, 2017 [Page 16]
Internet-Draft LPWAN Survey and Gap Analysis October 2016
Josep PAradells
UPC/i2CAT
C/Jordi Girona, 1-3
Barcelona 08034
Spain
Email: josep.paradells@entel.upc.edu
Jon Crowcroft
University of Cambridge
JJ Thomson Avenue
Cambridge, CB3 0FD
United Kingdom
Email: jon.crowcroft@cl.cam.ac.uk
Minaburo, et al. Expires April 22, 2017 [Page 17]
