Internet DRAFT - draft-minaburo-lp-wan-gap-analysis
draft-minaburo-lp-wan-gap-analysis
Network Working Group A. Minaburo
Internet-Draft A. Pelov
Intended status: Informational Acklio
Expires: August 27, 2016 L. Toutain
Institut MINES TELECOM ; TELECOM Bretagne
February 24, 2016
LP-WAN GAP Analysis
draft-minaburo-lp-wan-gap-analysis-01
Abstract
Low Power Wide Area Networks (LP-WAN) are different technologies
covering different applications based on long range, low bandwidth
and low power operation. The use of IETF protocols in the LP-WAN
technologies should contribute to the deployment of a wide number of
applications in an open and standard environment where actual
technologies will be able to communicate. This document makes a
survey of the principal characteristics of these technologies and
covers a cross layer analysis on how to adapt and use the actual IETF
protocols, but also the gaps for the integration of the IETF protocol
stack in the LP-WAN technologies.
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 August 27, 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
Minaburo, et al. Expires August 27, 2016 [Page 1]
Internet-Draft LP-WAN GAP Analysis February 2016
(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.
1. Introduction
LP-WAN (Low-Power Wide Area Network) technologies are a kind of
constrained and challenged networks [RFC7228]. They can operate in
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, LP-WAN devices are, as of today, with no
IP capabilities. The goal is to adapt IETF defined protocols,
addressing schemes and naming spaces to this constrained environment.
2. Problem Statement
The LP-WANs are large-scale constrained networks in the sense of
[RFC7228] with the following characteristics:
o very small frame payload as low as 12 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. Some nodes will exchange less than 10 frames per day.
o very low bandwidth, most LP-WAN technologies offer a throughput
between 50 bit/s to 250 kbit/s, with a duty cycle of 0.1% to 10%
on some ISM bands.
o high packet loss, which can be the result of bad transmission
conditions or collisions between nodes.
o variable MTU for a link depending on the used L2 modulation.
o highly asymmetric and in some cases unidirectional links.
o ultra dense networks with thousands to tens of thousands of nodes.
o different modulations and radio channels.
o sleepy nodes to preserve energy.
Minaburo, et al. Expires August 27, 2016 [Page 2]
Internet-Draft LP-WAN GAP Analysis February 2016
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, LP-WANs need to be
considered as a separate class of networks. The intrinsic
characteristics, current usages and architectures will allow the
group to make and justify the design choices. Some of the desired
properties are:
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 LP-WAN requirements,
such as:
* limited number of messages per device.
* small message size, with potentially no L2 fragmentation.
* RTTs potentially orders of magnitude bigger than existing
constrained networks.
o optimize the protocol stack in order to limit the number of
duplicated functionalities; for instance acknowledgements should
not be done at several layers.
3. Identified gaps in current IETF groups concerning LP-WANs
3.1. IPv6 and LP-WAN
IPv6 [RFC2460] has been designed to allocate addresses to all the
nodes connected to the Internet. Nevertheless the 40 bytes of
overhead introduced by the protocol are incompatible with the LP-WAN
constraints. If IPv6 were used, several LP-WAN frames will be needed
just to carry the header. Another limitation comes from the MTU
limit, which is 1280 bytes required from the layer 2 to carry IPv6
packet [RFC1981]. This is a side effect of the PMTU discovery
mechanism, which allows intermediary routers to send to the source an
ICMP message (packet too big) to reduce the size. An attacker will
be able to forge this message and reduce drastically the transmission
Minaburo, et al. Expires August 27, 2016 [Page 3]
Internet-Draft LP-WAN GAP Analysis February 2016
performances. This limit allows to mitigate the impact of this
attack.
IPv6 needs a configuration protocol (neighbor discovery protocol, NDP
[RFC4861]) to learn network parameters, and the node relation with
its neighbor. This protocol generates a regular traffic with a large
message size that does not fit LP-WAN constraints.
3.2. 6LoWPAN, 6lo and LP-WAN
6LoWPAN only resolves the IPv6 constraints by drastically reducing
IPv6 overhead to about 4 bytes for ND traffic, but the header
compression is not better for an end-to-end communications using
global addresses (up to 20 bytes). 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 with no duty cycle regarding the
usage of the network.
IEEE 802.15.4 is a CSMA/CA protocol which means that every unicast
frame is acknowledged. Because IEEE 802.15.4 has its own reliability
mechanism by retransmission, 6LoWPAN does not have reliable delivery.
Some LP-WAN technologies do not provide such acknowledgements at L2
and would require other reliability mechanisms.
6lo extends the usage of 6LoWPAN to other technologies (BLE, DECT,
...), with similar characteristics to IEEE 802.15.4. The main
constraint in these networks comes from the nature of the devices
(constrained devices), whereas in LP-WANs it is the network itself
that imposes the most stringent constraint.
Neighbor Discovery has to be optimized by reducing the message size,
the periodic exchanges and removing multicast message for point-to-
point exchanges with border router.
3.3. 6tisch and LP-WAN
TODO
Describe why 6tisch is complementary to LP-WAN
A key element of 6tisch is the use of synchronization to enable
determinism. An LP-WAN may or may not support synchronization like
the one used in 6tisch. The 6tisch solution is dedicated to mesh
networks that operate using 802.15.4e with a deterministic slotted
channel.
Minaburo, et al. Expires August 27, 2016 [Page 4]
Internet-Draft LP-WAN GAP Analysis February 2016
3.4. ROLL and LP-WAN
The LP-WANs considered by the 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. For the moment, the work
done at the ROLL WG and other routing protocols are out of scope of
the LP-WAN WG.
3.5. CORE and LP-WAN
TODO
CoRE provides a resource-oriented application 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. 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.
3.6. Security and LP-WAN
ToDo
3.7. Mobility and LP-WAN
TODO
LP-WAN nodes can be mobile. However, LP-WAN mobility is different
than the one studied in the context of Mobile IP. LP-WAN implies
sporadic traffic and will rarely be used for high-frequency, real-
time communications.
4. Annex A -- survey of LP-WAN technologies
Different technologies can be included under the LP-WAN 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 August 27, 2016 [Page 5]
Internet-Draft LP-WAN GAP Analysis February 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 |100 bps |12 B |
| |50 km rural | | |
+-------------+---------------+--------------+--------+
|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-LTE |< 15 km | < 150 kbps | < 200 B|
+-------------+---------------+--------------+--------+
Figure 1: Survey of LP-WAN technologies
The table Figure 1 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 August 27, 2016 [Page 6]
Internet-Draft LP-WAN GAP Analysis February 2016
5. Acknowledgements
Thanks you very much for the discussion and feedback on the LP-WAN
mailing list, namely, Pascal Thubert, Carles Gomez, Samita
Chakrabarti, Xavier Vilajosana, Misha Dohler, Florian Meier, Timothy
J. Salo, Michael Richardson, Robert Cragie, Paul Duffy, Pat Kinney,
Joaquin Cabezas and Bill Gage.
6. 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>.
[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>.
Authors' Addresses
Ana Minaburo
Acklio
2bis rue de la Chataigneraie
35510 Cesson-Sevigne Cedex
France
Email: ana@ackl.io
Alexander Pelov
Acklio
2bis rue de la Chataigneraie
35510 Cesson-Sevigne Cedex
France
Email: a@ackl.io
Minaburo, et al. Expires August 27, 2016 [Page 7]
Internet-Draft LP-WAN GAP Analysis February 2016
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 August 27, 2016 [Page 8]
