[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/