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

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 15 Mar 2016 13:16:18 +0100

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 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.

   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.

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.)

(Comment: some of the LPWAN 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.)

-------
   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.)

Suggestion:

   Therefore, most LP-WANs may require specific solutions extending
   existing IETF mechanisms and/or defining new ones.
-------

   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.
-------

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].
-------

   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

(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.)

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.

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: [email-masked]

   Alexander Pelov
   Acklio
   2bis rue de la Chataigneraie
   35510 Cesson-Sevigne Cedex
   France

   Email: [email-masked]

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: [email-masked]

Minaburo, et al.         Expires August 27, 2016                [Page 8]

---

From: Ana Minaburo <[email-masked]>
Date: Wed, 16 Mar 2016 17:06:10 +0100

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 <
[email-masked]> wrote:

> >> 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
> (AM) Good point to be added

> (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

> 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
> (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

> (Comment: separate from what? Also, there are other types of challenged

(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

>    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

> performance. A per-technology or per-scenario analysis is recommended.

(AM) Agree

> packet

(AM) Good, thanks

>    be able to forget this message and reduce drastically the transmission
>
> (AM) I can include this idea

> (AM) ok

> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: "weigengyu" <[email-masked]>
Date: Fri, 18 Mar 2016 10:57:41 +0800

Hi,

Need to give some explicit description on "large scale constrained 
networks"?
Suggest to make it more clear what large scale means whithin LP-WAN?

In the draft,  "2.  Problem Statement
   The LP-WANs are large-scale constrained networks in the sense of
   [RFC7228] with the following characteristics: "
As RFC7228 is about Terminology for Constrained-Node Networks, it is not on 
large scale.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Carles Gomez Montenegro
Sent: Tuesday, March 15, 2016 8:16 PM
To: [email-masked]
Subject: [lp-wan] Review and proposed text 
fordraft-minaburo-lp-wan-gap-analysis-01

Hi everyone,

Thanks!

Carles

---------------------------  Start  ------------------------------------

                          LP-WAN GAP Analysis

Abstract

Status of This Memo

Copyright Notice

1.  Introduction

2.  Problem Statement

-------
Suggestion:

-------

Suggestion:

   The intrinsic

-------

3.1.  IPv6 and LP-WAN

-------
OLD:

NEW:

   but the header

NEW:

3.3.  6tisch and LP-WAN

   TODO

3.4.  ROLL and LP-WAN

3.5.  CORE and LP-WAN

   TODO

NEW:

3.6.  Security and LP-WAN

   ToDo

3.7.  Mobility and LP-WAN

   TODO

5.  Acknowledgements

6.  Normative References

Authors' Addresses

   Ana Minaburo
   Acklio

   Email: [email-masked]

   Alexander Pelov
   Acklio

   Email: [email-masked]

   Laurent Toutain

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 18 Mar 2016 13:38:01 +0100

Hi Ana,

Thanks for your responses. Please see below some inline responses to your
responses:

<snipped>

>>                  draft-minaburo-lp-wan-gap-analysis-01

<snipped>

> included in the LP-WAN family.

OK, thanks.

<snipped>

> actual use is in an star topology but we can think about new usage with

I agree that we should not leave out other possible topologies. But maybe
if we exploit the "typically" in the above suggestion, we are still
considering all possible topologies, while emphasizing an aspect we might
optimize for. Anyway, this is not absolutely critical...

> be modified but we will use additional protocols or mechanisms in upper or

I would suggest to use in the draft some phrasing similar to your last
sentence (which has been clarifying), instead of the following current
text: "the IP connectivity has to be redefined or modified".

> network that cannot use 6lo or 6tisch technologies

I think that saying that *many* LPWAN fall in the challenged network
category still motivates possible work beyond the scope of 6lo, while
considering *all* LPWAN to be challenged networks is probably not true.
Maybe we just need to recognize that there is some not well defined
boundary between the different scopes.

> mechanisms to have the IP connectivity

I agree with your explanation.

> characteristics and solve this problematic

I was trying to say that e.g. maybe one solution is useful for several
different LP-WAN technologies (but specific to LP-WAN as a network class).
Of course, it would be great, and probably possible to develop generic
mechanisms (e.g. draft-gomez-lpwan-fragmentation-header) that can be used
for several specific technologies. However, specific technologies may
require at least some set of specific techniques (see for example the
plethora of IPv6 over foo specs in 6Lo(WPAN)).

<snipped>

>> fragment data, while the offset of each fragment has to be expressed in

<snipped>

Thanks,

Carles

---

From: "weigengyu" <[email-masked]>
Date: Tue, 22 Mar 2016 13:38:22 +0800

Hi,

I have a question about addressing description and scale of networks for 
LP-WAN.
AS LP-WAN is a large scale constrained networks, and one example of LP-WAN, 
SIGFOX,  has an L2 MTU of 12bytes and doest not support L2 fragmentation.
For the LP-WAN, such as SIGFOX,  is it a large scale network?

Regards,

Gengyu WEI
-----原始邮件----- 
From: Carles Gomez Montenegro
Sent: Friday, March 18, 2016 8:38 PM
To: Ana Minaburo
Cc: [email-masked]
Subject: Re: [lp-wan] Fwd: Review and proposed text for 

Hi Ana,

<snipped>

<snipped>

OK, thanks.

<snipped>

<snipped>

>> the (acknowledged) upper layers a lotâ€¦  If both things may be of
>> interest

<snipped>

Thanks,

Carles

---

From: "Eric Hamel (ehamel)" <[email-masked]>
Date: Fri, 25 Mar 2016 15:40:25 +0000

Chiming in late on this thread, apologies.

On the first comment, there will be licensed options for LPWA with NB-IOT and EC-GSM. As such, I believe that the gaps will equally apply to unlicensed (LoRa, SigFox, Weightless) and licensed LP-WAN access.

Thanks,
Eric