One document matched: draft-minaburo-lp-wan-gap-analysis-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc7228 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7228.xml'>
<!ENTITY rfc2460 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml'>
<!ENTITY rfc1981 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1981.xml'>
<!ENTITY rfc4861 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml'>
]>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<rfc category="info" docName="draft-minaburo-lp-wan-gap-analysis-01" ipr="trust200902">
<front>
<title abbrev="LP-WAN GAP Analysis">LP-WAN GAP Analysis</title>
<author fullname="Ana Minaburo" initials="A." surname="Minaburo">
<organization>Acklio</organization>
<address>
<postal>
<street>2bis rue de la Chataigneraie</street>
<city>35510 Cesson-Sevigne Cedex</city>
<country>France</country>
</postal>
<email>ana@ackl.io</email>
</address>
</author>
<author fullname="Alexander Pelov" initials="A." surname="Pelov">
<organization>Acklio</organization>
<address>
<postal>
<street>2bis rue de la Chataigneraie</street>
<city>35510 Cesson-Sevigne Cedex</city>
<country>France</country>
</postal>
<email>a@ackl.io</email>
</address>
</author>
<author fullname="Laurent Toutain" initials="L." surname="Toutain">
<organization>Institut MINES TELECOM ; TELECOM Bretagne</organization>
<address>
<postal>
<street>2 rue de la Chataigneraie</street>
<street>CS 17607</street>
<city>35576 Cesson-Sevigne Cedex</city>
<country>France</country>
</postal>
<email>Laurent.Toutain@telecom-bretagne.eu</email>
</address>
</author>
<date month="February" year="2016" />
<!-- <workgroup>v6ops Working Group </workgroup> -->
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>
LP-WAN (Low-Power Wide Area Network) technologies are a kind of constrained and challenged networks <xref target='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.
</t>
</section>
<section anchor="ProblemStatement" title="Problem Statement">
<t>
The LP-WANs are large-scale constrained networks in the sense of <xref target='RFC7228'/> with the following characteristics:
<list style="symbols">
<t>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.</t>
<t>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.</t>
<t>high packet loss, which can be the result of bad transmission conditions or collisions between nodes.</t>
<t>variable MTU for a link depending on the used L2 modulation.</t>
<t>highly asymmetric and in some cases unidirectional links.</t>
<t>ultra dense networks with thousands to tens of thousands of nodes.</t>
<t>different modulations and radio channels.</t>
<t>sleepy nodes to preserve energy.</t>
</list>
</t>
<!--
<t>
The work will not address the constraints of a node. A node may be of Class 0
with a very limited processing capabilities sending periodically measurement in an unidirectional
link, or Class 1 or Class 2 or even be a non-constrained device.
</t>
-->
<t>
In the terminology of <xref target='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:
<list style="symbols">
<t>keep compatibility with current Internet:
<list style="symbols">
<t>preserve the end-to-end communication principle.</t>
<t>maintain independence from L2 technology.</t>
<t>use or adapt protocols defined by IETF to this new environment that could be less responsive.</t>
<t>use existing addressing spaces and naming schemes defined by IETF.</t>
</list></t>
<t>ensure the correspondence with the stringent LP-WAN requirements, such as:
<list style="symbols">
<t>limited number of messages per device.</t>
<t>small message size, with potentially no L2 fragmentation.</t>
<t>RTTs potentially orders of magnitude bigger than existing constrained networks.</t>
</list></t>
<t>optimize the protocol stack in order to limit the number of duplicated functionalities; for instance acknowledgements should not be done at several layers.
</t>
</list>
</t>
</section>
<section anchor="Gap" title="Identified gaps in current IETF groups concerning LP-WANs">
<section anchor="IPv6" title="IPv6 and LP-WAN">
<t>IPv6 <xref target='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 <xref target="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 performances. This limit allows to mitigate the
impact of this attack.
</t>
<t>
IPv6 needs a configuration protocol (neighbor discovery protocol, NDP <xref target="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.
</t>
</section>
<section anchor="SIXlo" title="6LoWPAN, 6lo and LP-WAN">
<t>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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="SIXtisch" title="6tisch and LP-WAN">
<t>
TODO
</t><t>
Describe why 6tisch is complementary to LP-WAN
</t><t>
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.
</t>
</section>
<section anchor="ROLL" title="ROLL and LP-WAN">
<t>
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.
</t>
</section>
<section anchor="CORE" title="CORE and LP-WAN">
<t>
TODO
</t><t>
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.
</t>
</section>
<section anchor="Security" title="Security and LP-WAN">
<t>
ToDo
</t>
</section>
<section anchor="Mobility" title="Mobility and LP-WAN">
<t>
TODO
</t><t>
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.
</t>
</section>
</section>
<section anchor="annexA" title="Annex A -- survey of LP-WAN technologies">
<t>
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.
<!--(https://docs.google.com/document/d/1n7cXN4_VuI8imy8MG3-fHjl9FNiNvYfdB4txN4hDQ-w/edit?usp=sharing)-->
<figure anchor="tableLPWAN"
title="Survey of LP-WAN technologies"><artwork><![CDATA[
+-------------+---------------+--------------+--------+
|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|
+-------------+---------------+--------------+--------+
]]></artwork></figure>
</t>
<t>
The table <xref target="tableLPWAN" /> 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.
</t>
<t>
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.
</t>
</section>
<!-- ACK -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
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.
</t>
</section>
<!-- fin -->
</middle>
<back>
<references title="Normative References">
&rfc7228;
&rfc2460;
&rfc1981;
&rfc4861;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:37:53 |