Re: [lp-wan] Fwd: Review and proposed text for draft-minaburo-lp-wan-gap-analysis-01

[Behcet Sarikaya <[e-mail]>]

Hi Ana,

I saw in your draft you mentioned NB-LTE  in licensed channel as an
LP-WAN technology.
My question is if you included 3GPP M2M work like small data
transmission enhancements in your GAP analysis. I think that there is
work going on to define unlicensed spectrum LTE which should also be
included among LP-WAN technologies.

Regards,

Behcet

On Wed, Mar 16, 2016 at 11:06 AM, Ana Minaburo <[e-mail]> wrote:
>
> Thank you very much for your comments, see my answers in the text
>
> Ana
>
> On Tue, Mar 15, 2016 at 1:16 PM, Carles Gomez Montenegro
> <[e-mail]> wrote:
>>
>> Hi everyone,
>>
>> Please find below a review with comments and suggested new text for
>> draft-minaburo-lp-wan-gap-analysis-01.
>>
>> Thanks!
>>
>> Carles
>>
>>
>> ---------------------------  Start  ------------------------------------
>>
>> 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
>> >> licensed
>
>
> (AM) We think it could create a confusion with the cellular networks
> (3G,4G,5G technologies) that are licensed and that we do not want to be
> included in the LP-WAN family.
>>
>> 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, 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  in many cases, lack of L2 fragmentation.
>>
> (AM) Good point to be added
>
>>
>>    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.
>>
>> >> o  typically, they define a star topology.
>>
>>
> (AM) Here also, It is true that most of the actual topologies are star, but
> this will quickly put many future possibilities out of the scope. The actual
> use is in an star topology but we can think about new usage with another
> topology
>>
>>
>>
>> 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.
>>
>> -------
>> Suggestion:
>>
>>    In the terminology of [RFC7228], these characteristics put many LP-WAN
>>    technologies (and/or technology configurations) into the "challenged
>>    network" category where end-to-end connectivity requires the addition
>> of
>>    new mechanisms to the existing ones.
>>
>> (Comment: note that in DTNs, IP connectivity is not modified per se;
>> instead, additional mechanisms are added at upper layers.)
>
>
> (AM) I think that in LP-WAN will be the same, the IP connectivity will not
> be modified but we will use additional protocols or mechanisms in upper or
> lower layers
>>
>>
>> (Comment: some of the LP-WAN technologies, depending on how they are
>> configured, e.g. the modulation used, do not actually fall in the
>> challenged network category, but are probably still constrained networks.)
>>
> (AM) Of course modulation is variable so we can in some cases be only
> constrained but this work is already the scope of other working groups as
> 6lo or 6tisch and the objective is to do what is needed for challenged
> network that cannot use 6lo or 6tisch technologies
>
>>
>> -------
>>    Therefore, LP-WANs need to be
>>    considered as a separate class of networks.
>>
>> (Comment: separate from what? Also, there are other types of challenged
>> networks.)
>
>
> (AM) Yes perhaps it is not clear. What we want to do is to assemble LP-WAN
> technologies into a family or group or class of networks which has some
> common characteristics and are challenged, and need some additional
> mechanisms to have the IP connectivity
>>
>>
>> Suggestion:
>>
>>    Therefore, most LP-WANs may require specific solutions extending
>>    existing IETF mechanisms and/or defining new ones.
>
>
> (AM) If we create a solution for each LP-WAN technology will not be simple,
> it is better to crete a group of LP-WAN technologies that has common
> characteristics and solve this problematic
>>
>> -------
>>
>>    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.
>>
>> -------
>>
>> (Comment: why? Sometimes, lower layer (e.g. link layer) reliability helps
>> the (acknowledged) upper layers a lot…  If both things may be of interest
>> depending on the scenario/technology, it could be good to state it.)
>>
>> Suggestion: To minimize the number of messages to be exchanged, upper
>> layer acknowledgments can be used. Nevertheless, if appropriately tuned,
>> lower layer reliability may contribute to achieve a higher overall
>> performance. A per-technology or per-scenario analysis is recommended.
>
>
> (AM) Agree
>>
>> -------
>>
>>
>> 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.
>>
>> -------
>> OLD:
>>    Another limitation comes from the MTU
>>    limit, which is 1280 bytes required from the layer 2 to carry IPv6
>> packet
>>    [RFC1981].
>>
>> NEW:
>>    Another limitation comes from the MTU of 1280 bytes required by IPv6
>>    [RFC2460].
>
>
> (AM) Good, thanks
>>
>> -------
>>
>>    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 forget this message and reduce drastically the transmission
>>
>> (Comment: I think a reason for the IPv6 MTU requirement was the increase
>> of link layer technologies capacity by the time (compared with the state
>> of art when IPv4 was designed, where an MTU of 576 bytes was defined), and
>> also to allow an efficiency increase.)
>>
> (AM) I can include this idea
>>
>>
>> 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,
>>
>> (Comment: What are the 4 bytes this sentence refers to?)
>> (Comment: 6LoWPAN comprises other important mechanisms, such as
>> fragmentation.)
>>
>>    but the header
>>    compression is not better for an end-to-end communications using
>>    global addresses (up to 20 bytes).
>>
>> (Comment: but down to 3 bytes using global addresses, in the best case.)
>>
>>    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.
>>
>> (Comment: 802.15.4 beacon-enabled mode is duty-cycled. Also channel
>> sampling can be used, and is still duty cycled. 6LoWPAN can be used on top
>> of both beacon and nonbeacon-enabled networks (RFC 4944).)
>>
>>    IEEE 802.15.4 is a CSMA/CA protocol which means that every unicast
>>    frame is acknowledged.
>>
>> (Comment: No. 802.15.4 provides optional reliability. A bit in the header
>> of a frame signals whether the frame requires an acknowledgment or not.)
>>
>>    Because IEEE 802.15.4 has its own reliability
>>    mechanism by retransmission, 6LoWPAN does not have reliable delivery.
>>
>> (Comment: 6LoWPAN does not have reliable delivery because it just needs to
>> adapt IPv6 (which does not have reliable delivery) over a link layer.
>> Whatever happens below 6LoWPAN is a responsibility of the link layer,
>> which may be reliable or not.)
>>
>>    Some LP-WAN technologies do not provide such acknowledgements at L2
>>    and would require other reliability mechanisms.
>>
>> NEW:
>> A key 6LoWPAN component is fragmentation, which allows the transmission of
>> IPv6 packets greater than the available payload in IEEE 802.15.4 (of 81
>> bytes in the worst case), and allows to fulfill the IPv6 MTU requirement.
>> However, for example, in the LP-WAN technology called SIGFOX, which has an
>> L2 MTU of 12 bytes and does not support L2 fragmentation, it is not
>> possible to transmit large IPv6 packets by using RFC 4944 6LoWPAN
>> fragmentation, since the 6LoWPAN fragmentation header consumes 5 bytes
>> (4 bytes for the first fragment), leaving only 7 bytes of space for
>> fragment data, while the offset of each fragment has to be expressed in
>> increments of 8 octets.
>>
> (AM) ok
>
>>
>> On the other hand, in L2 technologies with an L2 maximum payload size of
>> 13 or more bytes, it will be possible to transmit any IPv6 packet by using
>> 6LoWPAN fragmentation. However, a large overhead will be incurred, leading
>> to a very high number of L2 data units per single IPv6 packet.
>>
>> An optimized, 3-byte 6LoWPAN fragmentation header has been defined in
>> [draft-gomez-lpwan-fragmentation-header], exploiting LP-WAN
>> characteristics. This fragmentation header enables the support of IPv6
>> packets over L2 payload sizes of even 4 bytes in the most extreme case,
>> and reduces a significant amount of both L2 and adaptation layer overhead.
>
>
>>
>>    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.
>>
>> (Comment: The devices in 6lo and 6LoWPAN are constrained, but their
>> networks are also constrained in terms of RFC 7228 (section 2.2). I would
>> say that the difference between LP-WANs and 6LoWPAN is that many LP-WANs
>> can be considered to be "challenged networks". Nevertheless, there is
>> probably not a well-defined boundary between 6Lo(WPAN) and LP-WAN.)
>>
>>    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.
>>
>> (Comment: Does this refer to IPv6 ND, or to 6LoWPAN ND?
>> RFC 6775 removes multicast as much as possible. On the other hand, the
>> registration lifetime can be of up to 1.5 months in 6LoWPAN ND.)
>>
>>
>> 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.
>>
>> NEW:
>> For example, while the CoAP RTO timer is chosen randomly from the [2 s, 3
>> s] interval by default, the transmission time of the largest L2 data unit
>> size, using the most robust modulation, is 6.82 s with LoRa, 9.6 s with
>> SIGFOX, and 85 s with IEEE 802.15.4k LECIM.
>>
>>    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    |              |        |
>>    +-------------+---------------+--------------+--------+
>>
>> (Comment: I have a SIGFOX flyer (date July 2012) which states a range
>> between 10 bit/s and 1 kbit/s.)
>>
>>    |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: [e-mail]
>>
>>
>>    Alexander Pelov
>>    Acklio
>>    2bis rue de la Chataigneraie
>>    35510 Cesson-Sevigne Cedex
>>    France
>>
>>    Email: [e-mail]
>>
>>
>>
>>
>>
>> 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: [e-mail]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Minaburo, et al.         Expires August 27, 2016                [Page 8]
>>
>>
>>
>> _______________________________________________
>> lp-wan mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>
>
>
>
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan
>