Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 8376

Low-Power Wide Area Network (LPWAN) Overview

Pages: 43
Part 2 of 2 – Pages 24 to 43
First   Prev   None

Top   ToC   RFC8376 - Page 24   prevText

3. Generic Terminology

LPWAN technologies, such as those discussed above, have similar architectures but different terminology. We can identify different types of entities in a typical LPWAN network: o End devices are the devices or the "things" (e.g., sensors, actuators, etc.); they are named differently in each technology (End Device, User Equipment, or EP). There can be a high density of end devices per Radio Gateway. o The Radio Gateway, which is the EP 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 the Network Server, Serving GW, or Service Center. o LPWAN-AAA server, which controls user authentication. It is known as the Join-Server, Home Subscriber Server, or Registration Authority. (We use the term LPWAN-AAA server because we're not assuming that this entity speaks RADIUS or Diameter as many/most AAA servers do; but, equally, we don't want to rule that out, as the functionality will be similar.) o At last we have the Application Server, known also as Packet Data Node Gateway or Network Application.
Top   ToC   RFC8376 - Page 25
 | Function/ |           |           |            |        |           |
 |Technology |  LoRaWAN  |   NB-IoT  |   Sigfox   | Wi-SUN |    IETF   |
 |Sensor,    |           |           |            |        |           |
 |Actuator,  |    End    |    User   |     End    |  Leaf  |   Device  |
 |device,    |  Device   | Equipment |    Point   |  Node  |   (DEV)   |
 |object     |           |           |            |        |           |
 |Transceiver|           |  Evolved  |    Base    | Router |   Radio   |
 |Antenna    |  Gateway  |  Node B   |   Station  |  Node  |  Gateway  |
 |Server     |  Network  |  PDN GW/  |   Service  | Border |  Network  |
 |           |  Server   |   SCEF*   |   Center   | Router |  Gateway  |
 |           |           |           |            |        |   (NGW)   |
 |Security   |   Join    |    Home   |Registration|Authent.|  LPWAN-   |
 |Server     |  Server   | Subscriber| Authority  | Server |   AAA     |
 |           |           |   Server  |            |        |  Server   |
 |Application|Application|Application|  Network   |Appli-  |Application|
 |           |   Server  |  Server   | Application| cation |   (App)   |

 * SCEF = Service Capability Exposure Function

                 Figure 9: LPWAN Architecture Terminology

 ()    ()   ()         |                         |LPWAN-|
   ()  () () ()       / \         +---------+    | AAA  |
() () () () () ()    /   \========|    /\   |====|Server|  +-----------+
 ()  ()   ()        |             | <--|--> |    +------+  |APPLICATION|
()  ()  ()  ()     / \============|    v    |==============|    (App)  |
  ()  ()  ()      /   \           +---------+              +-----------+
 DEV         Radio Gateways           NGW

                       Figure 10: LPWAN Architecture

   In addition to the names of entities, LPWANs are also subject to
   possibly regional frequency-band regulations.  Those may include
   restrictions on the duty cycle, for example, requiring that hosts
   only transmit for a certain percentage of each hour.
Top   ToC   RFC8376 - Page 26

4. Gap Analysis

This section considers some of the gaps between current LPWAN technologies and the goals of the LPWAN WG. Many of the generic considerations described in [RFC7452] will also apply in LPWANs, as end devices can also be considered to be a subclass of (so-called) "smart objects". In addition, LPWAN device implementers will also need to consider the issues relating to firmware updates described in [RFC8240].

4.1. Naive Application of IPv6

IPv6 [RFC8200] 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 LPWAN constraints. If IPv6 with no further optimization were used, several LPWAN frames could be needed just to carry the IP header. Another problem arises from IPv6 MTU requirements, which require the layer below to support at least 1280 byte packets [RFC2460]. IPv6 has a configuration protocol: Neighbor Discovery Protocol (NDP) [RFC4861]). For a node to learn network parameters, NDP generates regular traffic with a relatively large message size that does not fit LPWAN constraints. In some LPWAN technologies, L2 multicast is not supported. In that case, if the network topology is a star, the solution and considerations from Section 3.2.5 of [RFC7668] may be applied. Other key protocols (such as DHCPv6 [RFC3315], IPsec [RFC4301] and TLS [RFC5246]) have similarly problematic properties in this context. Each protocol requires relatively frequent round-trips between the host and some other host on the network. In the case of cryptographic protocols (such as IPsec and TLS), in addition to the round-trips required for secure session establishment, cryptographic operations can require padding and addition of authenticators that are problematic when considering LPWAN lower layers. Note that mains powered Wi-SUN mesh router nodes will typically be more resource capable than the other LPWAN technologies discussed. This can enable use of more "chatty" protocols for some aspects of Wi-SUN.

4.2. 6LoWPAN

Several technologies that exhibit significant constraints in various dimensions have exploited the 6LoWPAN suite of specifications ([RFC4944], [RFC6282], and [RFC6775]) to support IPv6 [USES-6LO]. However, the constraints of LPWANs, often more extreme than those typical of technologies that have (re-)used 6LoWPAN, constitute a
Top   ToC   RFC8376 - Page 27
   challenge for the 6LoWPAN suite in order to enable IPv6 over LPWAN.
   LPWANs are characterized by device constraints (in terms of
   processing capacity, memory, and energy availability), and
   especially, link constraints, such as:

   o  tiny L2 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.

4.2.1. 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 the most extreme case. However, in more practical situations, the smallest 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 was initially designed for [IEEE.802.15.4] networks with a frame size up to 127 bytes and a throughput of up to 250 kbit/s, which may or may not be duty cycled.

4.2.2. Address Autoconfiguration

Traditionally, Interface Identifiers (IIDs) have been derived from link-layer identifiers [RFC4944]. This allows optimizations 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. [RFC8065] provides guidance on better methods for generating IIDs.

4.2.3. Fragmentation

As stated above, IPv6 requires the layer below to support an MTU of 1280 bytes [RFC8200]. Therefore, given the low maximum payload size of LPWAN technologies, fragmentation is needed.
Top   ToC   RFC8376 - Page 28
   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 the 2003 version of [IEEE.802.15.4] (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 the 2003 version of
   [IEEE.802.15.4].  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.

4.2.4. Neighbor Discovery

6LoWPAN Neighbor Discovery [RFC6775] defines optimizations to IPv6 ND [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 ND 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 ND behavior may be tuned through the use of appropriate values for the default Router Lifetime, the Valid Lifetime in the PIOs, and the
Top   ToC   RFC8376 - Page 29
   Valid Lifetime in the 6LoWPAN Context Option (6CO), as well as the
   address Registration Lifetime.  However, for the latter LPWANs
   mentioned above, 6LoWPAN ND is not suitable.

4.3. 6lo

The 6lo WG has been reusing and adapting 6LoWPAN to enable IPv6 support over link-layer technologies such as Bluetooth Low Energy (BTLE), ITU-T G.9959 [G9959], Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE), MS/TP-RS485, Near Field Communication (NFC) IEEE 802.11ah. (See <> for details on the 6lo WG.) These technologies are similar in several aspects to [IEEE.802.15.4], which was the original 6LoWPAN target technology. 6lo has mostly used the subset of 6LoWPAN techniques best suited for each lower-layer technology and has provided additional optimizations for technologies where the star topology is used, such as BTLE 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.

4.4. 6tisch

The IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) solution is dedicated to mesh networks that operate using [IEEE.802.15.4e] MAC with a deterministic slotted channel. Time-Slotted Channel Hopping (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.

4.5. RoHC

RoHC is a header compression mechanism [RFC3095] developed for multimedia flows in a point-to-point channel. RoHC uses three levels of compression, each level having its own header format. In the first level, RoHC sends 52 bytes of header; in the second level, the header could be from 34 to 15 bytes; and in the third level, header size could be from 7 to 2 bytes. The level of compression is managed by a Sequence Number (SN), which varies in size from 2 bytes to 4 bits in the minimal compression. SN compression is done with an
Top   ToC   RFC8376 - Page 30
   algorithm called Window-Least Significant Bits (W-LSB).  This window
   has a 4-bit size representing 15 packets, so every 15 packets, RoHC
   needs to slide the window in order to receive the correct SN, and
   sliding the window implies a reduction of the level of compression.
   When packets are lost or errored, the decompressor loses context and
   drops packets until a bigger header is sent with more complete
   information.  To estimate the performance of RoHC, an average header
   size is used.  This average depends on the transmission conditions,
   but most of the time is between 3 and 4 bytes.

   RoHC has not been adapted specifically to the constrained hosts and
   networks of LPWANs: it does not take into account energy limitations
   nor the transmission rate.  Additionally, RoHC context is
   synchronized during transmission, which does not allow better

4.6. ROLL

Most technologies considered by the LPWAN WG are based on a star topology, which eliminates the need for routing at that layer. Future work may address additional use cases that may require adaptation of existing routing protocols or the definition of new ones. As of the time of writing, work similar to that done in the Routing Over Low-Power and Lossy Network (ROLL) WG and other routing protocols are out of scope of the LPWAN WG.

4.7. CoAP

The Constrained Application Protocol (CoAP) [RFC7252] provides a RESTful framework for applications intended to run on constrained IP networks. It may be necessary to adapt CoAP or related protocols to take into account the extreme duty cycles 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 acknowledgments may allow the reduction of L2 acknowledgments. On the other hand, the current work in progress in the CoRE WG where the Constrained Management Interface (COMI) / Constrained Objects Language (CoOL) network management interface which, uses Structured Identifiers (SIDs) to reduce payload size over CoAP may prove to be a good solution for the LPWAN technologies. The overhead is reduced by adding a dictionary that matches a URI to a small identifier and a compact mapping of the YANG data model into the Concise Binary Object Representation (CBOR).
Top   ToC   RFC8376 - Page 31

4.8. Mobility

LPWAN 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. In addition, LPWAN mobility may mostly apply to groups of devices that represent a network; in which case, mobility is more a concern for the Gateway than the devices. Network Mobility (NEMO) [RFC3963] or other mobile Gateway solutions (such as a Gateway with an LTE uplink) may be used in the case where some end devices belonging to the same network Gateway move from one point to another such that they are not aware of being mobile.

4.9. DNS and LPWAN

The Domain Name System (DNS) [RFC1035], enables applications to name things with a globally resolvable name. Many protocols use the DNS to identify hosts, for example, applications using CoAP. The DNS query/answer protocol as a precursor to other communication within the Time-To-Live (TTL) of a DNS answer is clearly problematic in an LPWAN, say where only one round-trip per hour can be used, and with a TTL that is less than 3600 seconds. It is currently unclear whether and how DNS-like functionality might be provided in LPWANs.

5. Security Considerations

Most LPWAN technologies integrate some authentication or encryption mechanisms that were defined outside the IETF. The LPWAN WG may need to do work to integrate these mechanisms to unify management. A standardized Authentication, Authorization, and Accounting (AAA) infrastructure [RFC2904] may offer a scalable solution for some of the security and management issues for LPWANs. AAA offers centralized management that may be of use in LPWANs, for example [LoRaWAN-AUTH] and [LoRaWAN-RADIUS] suggest possible security processes for a LoRaWAN network. Similar mechanisms may be useful to explore for other LPWAN technologies. Some applications using LPWANs may raise few or no privacy considerations. For example, temperature sensors in a large office building may not raise privacy issues. However, the same sensors, if deployed in a home environment, and especially if triggered due to human presence, can raise significant privacy issues: if an end device emits a (encrypted) packet every time someone enters a room in a home, then that traffic is privacy sensitive. And the more that
Top   ToC   RFC8376 - Page 32
   the existence of that traffic is visible to network entities, the
   more privacy sensitivities arise.  At this point, it is not clear
   whether there are workable mitigations for problems like this.  In a
   more typical network, one would consider defining padding mechanisms
   and allowing for cover traffic.  In some LPWANs, those mechanisms may
   not be feasible.  Nonetheless, the privacy challenges do exist and
   can be real; therefore, some solutions will be needed.  Note that
   many aspects of solutions in this space may not be visible in IETF
   specifications but can be, e.g., implementation or deployment

   Another challenge for LPWANs will be how to handle key management and
   associated protocols.  In a more traditional network (e.g., the Web),
   servers can "staple" Online Certificate Status Protocol (OCSP)
   responses in order to allow browsers to check revocation status for
   presented certificates [RFC6961].  While the stapling approach is
   likely something that would help in an LPWAN, as it avoids an RTT,
   certificates and OCSP responses are bulky items and will prove
   challenging to handle in LPWANs with bounded bandwidth.

6. IANA Considerations

This document has no IANA actions.

7. Informative References

[ANSI-4957-000] ANSI/TIA, "Architecture Overview for the Smart Utility Network", ANSI/TIA-4957.0000 , May 2013. [ANSI-4957-210] ANSI/TIA, "Multi-Hop Delivery Specification of a Data Link Sub-Layer", ANSI/TIA-4957.210 , May 2013. [arib_ref] ARIB, "920MHz-Band Telemeter, Telecontrol and Data Transmission Radio Equipment", ARIB STD-T108 Version 1.0, February 2012. [ETSI-TS-102-887-2] ETSI, "Electromagnetic compatibility and Radio spectrum Matters (ERM); Short Range Devices; Smart Metering Wireless Access Protocol; Part 2: Data Link Layer (MAC Sub-layer)", ETSI TS 102 887-2, Version V1.1.1, September 2013.
Top   ToC   RFC8376 - Page 33
              ETSI, "Short Range Devices (SRD) operating in the
              frequency range 25 MHz to 1 000 MHz; Part 1: Technical
              characteristics and methods of measurement", Draft ETSI
              EN 300-220-1, Version V3.1.0, May 2016.

              ETSI, "Short Range Devices (SRD) operating in the
              frequency range 25 MHz to 1 000 MHz; Part 2: Harmonised
              Standard covering the essential requirements of article
              3.2 of Directive 2014/53/EU for non specific radio
              equipment", Final draft ETSI EN 300-220-2 P300-220-2,
              Version V3.1.1, November 2016.

   [etsi_unb] ETSI ERM, "System Reference document (SRdoc); Short Range
              Devices (SRD); Technical characteristics for Ultra Narrow
              Band (UNB) SRDs operating in the UHF spectrum below 1
              GHz", ETSI TR 103 435, Version V1.1.1, February 2017.

   [EUI64]    IEEE, "Guidelines for 64-bit Global Identifier
              (EUI),Organizationally Unique Identifier (OUI), and
              Company ID (CID)", August 2017,

   [FANOV]    IETF, "Wi-SUN Alliance Field Area Network (FAN) Overview",
              IETF 97, November 2016,

   [fcc_ref]  "Telecommunication Radio Frequency Devices - Operation
              within the bands 902-928 MHz, 2400-2483.5 MHz, and
              5725-5850 MHz.", FCC CFR 47 15.247, June 2016.

   [G9959]    ITU-T, "Short range narrow-band digital radiocommunication
              transceivers - PHY, MAC, SAR and LLC layer
              specifications", ITU-T Recommendation G.9959, January
              2015, <>.

              IEEE, "IEEE Standard for Information technology--
              Telecommunications and information exchange between
              systems Local and metropolitan area networks--Specific
              requirements Part 11: Wireless LAN Medium Access Control
              (MAC) and Physical Layer (PHY) Specifications",
              IEEE 802.11.
Top   ToC   RFC8376 - Page 34
              IEEE, "Upper Layer Interface (ULI) for IEEE 802.15.4 Low-
              Rate Wireless Networks", IEEE 802.15.12.

              IEEE, "IEEE Standard for Low-Rate Wireless Networks",
              IEEE 802.15.4, <

              IEEE, "IEEE Standard for Local and metropolitan area
              networks--Part 15.4: Low-Rate Wireless Personal Area
              Networks (LR-WPANs) Amendment 1: MAC sublayer",
              IEEE 802.15.4e.

              IEEE, "IEEE Standard for Local and metropolitan area
              networks--Part 15.4: Low-Rate Wireless Personal Area
              Networks (LR-WPANs) Amendment 3: Physical Layer (PHY)
              Specifications for Low-Data-Rate, Wireless, Smart Metering
              Utility Networks", IEEE 802.15.4g.

              IEEE, "IEEE Recommended Practice for Transport of Key
              Management Protocol (KMP) Datagrams", IEEE Standard
              802.15.9, 2016, <

              ANSI/IEEE, "IEEE Standard for Local and metropolitan area
              networks - Secure Device Identity", IEEE 802.1AR.

              IEEE, "Port Based Network Access Control", IEEE 802.1x.

   [LoRaSpec] LoRa Alliance, "LoRaWAN Specification Version V1.0.2",
              July 2016, <

   [LoRaWAN]  Farrell, S. and A. Yegin, "LoRaWAN Overview", Work in
              Progress, draft-farrell-lpwan-lora-overview-01, October

              Garcia, D., Marin, R., Kandasamy, A., and A. Pelov,
              "LoRaWAN Authentication in Diameter", Work in Progress,
              draft-garcia-dime-diameter-lorawan-00, May 2016.
Top   ToC   RFC8376 - Page 35
              Garcia, D., Lopez, R., Kandasamy, A., and A. Pelov,
              "LoRaWAN Authentication in RADIUS", Work in Progress,
              draft-garcia-radext-radius-lorawan-03, May 2017.

              Minaburo, A., Ed., Gomez, C., Ed., Toutain, L., Paradells,
              J., and J. Crowcroft, "LPWAN Survey and GAP Analysis",
              Work in Progress, draft-minaburo-lpwan-gap-analysis-02,
              October 2016.

   [NB-IoT]   Ratilainen, A., "NB-IoT characteristics", Work in
              Progress, draft-ratilainen-lpwan-nb-iot-00, July 2016.

   [nbiot-ov] IEEE, "NB-IoT Technology Overview and Experience from
              Cloud-RAN Implementation", Volume 24, Issue 3 Pages 26-32,
              DOI 10.1109/MWC.2017.1600418, June 2017.

   [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,

   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <>.

   [RFC2904]  Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
              Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
              D. Spence, "AAA Authorization Framework", RFC 2904,
              DOI 10.17487/RFC2904, August 2000,

   [RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
              Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
              K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
              Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
              Compression (ROHC): Framework and four profiles: RTP, UDP,
              ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095,
              July 2001, <>.
Top   ToC   RFC8376 - Page 36
   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <>.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, DOI 10.17487/RFC3963, January 2005,

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, DOI 10.17487/RFC4443, March 2006,

   [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,

   [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,

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
              March 2008, <>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
Top   ToC   RFC8376 - Page 37
   [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,

   [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,

   [RFC6961]  Pettersen, Y., "The Transport Layer Security (TLS)
              Multiple Certificate Status Request Extension", RFC 6961,
              DOI 10.17487/RFC6961, June 2013,

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,

   [RFC7452]  Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
              "Architectural Considerations in Smart Object Networking",
              RFC 7452, DOI 10.17487/RFC7452, March 2015,

   [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,

   [RFC8065]  Thaler, D., "Privacy Considerations for IPv6 Adaptation-
              Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
              February 2017, <>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,

   [RFC8240]  Tschofenig, H. and S. Farrell, "Report from the Internet
              of Things Software Update (IoTSU) Workshop 2016",
              RFC 8240, DOI 10.17487/RFC8240, September 2017,
Top   ToC   RFC8376 - Page 38
   [Sigfox]   Zuniga, J. and B. PONSARD, "Sigfox System Description",
              Work in Progress,
              draft-zuniga-lpwan-sigfox-system-description-04, December

              3GPP, "Study on architecture enhancements for Cellular
              Internet of Things", 3GPP TS 23.720 13.0.0, 2016.

              3GPP, "3G security; Access security for IP-based
              services", 3GPP TS 23.203 13.1.0, 2016.

              3GPP, "Evolved Universal Terrestrial Radio Access
              (E-UTRA); LTE physical layer; General description", 3GPP
              TS 36.201 13.2.0, 2016.

              3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA)
              and Evolved Universal Terrestrial Radio Access Network
              (E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300
              13.4.0, 2016,

              3GPP, "Evolved Universal Terrestrial Radio Access
              (E-UTRA); Medium Access Control (MAC) protocol
              specification", 3GPP TS 36.321 13.2.0, 2016.

              3GPP, "Evolved Universal Terrestrial Radio Access
              (E-UTRA); Radio Link Control (RLC) protocol
              specification", 3GPP TS 36.322 13.2.0, 2016.

              3GPP, "Evolved Universal Terrestrial Radio Access
              (E-UTRA); Packet Data Convergence Protocol (PDCP)
              specification (Not yet available)", 3GPP TS 36.323 13.2.0,

              3GPP, "Evolved Universal Terrestrial Radio Access
              (E-UTRA); Radio Resource Control (RRC); Protocol
              specification", 3GPP TS 36.331 13.2.0, 2016.
Top   ToC   RFC8376 - Page 39
   [USES-6LO] Hong, Y., Gomez, C., Choi, Y-H., and D-Y. Ko, "IPv6 over
              Constrained Node Networks(6lo) Applicability & Use cases",
              Work in Progress, draft-hong-6lo-use-cases-03, October

              Beecher, P., "Wi-SUN Alliance", March 2017,

              Heile, B., "Wi-SUN Alliance Field Area Network
              (FAN)Overview", As presented at IETF 97, November 2016,


Thanks to all those listed in the Contributors section for the excellent text. Errors in the handling of that are solely the editor's fault. In addition to those in the Contributors section, thanks are due to (in alphabetical order) the following for comments: Abdussalam Baryun Andy Malis Arun ( Behcet SariKaya Dan Garcia Carrillo Jiazi Yi Mirja Kuhlewind Paul Duffy Russ Housley Samita Chakrabarti Thad Guidry Warren Kumari Alexander Pelov and Pascal Thubert were the LPWAN WG Chairs while this document was developed. Stephen Farrell's work on this memo was supported by Pervasive Nation, the Science Foundation Ireland's CONNECT centre national IoT network <>.
Top   ToC   RFC8376 - Page 40


As stated above, this document is mainly a collection of content developed by the full set of contributors listed below. The main input documents and their authors were: o Text for Section 2.1 was provided by Alper Yegin and Stephen Farrell in [LoRaWAN]. o Text for Section 2.2 was provided by Antti Ratilainen in [NB-IoT]. o Text for Section 2.3 was provided by Juan Carlos Zuniga and Benoit Ponsard in [Sigfox]. o Text for Section 2.4 was provided via personal communication from Bob Heile and was authored by Bob and Sum Chin Sean. There is no Internet-Draft for that at the time of writing. o Text for Section 4 was provided by Ana Minabiru, Carles Gomez, Laurent Toutain, Josep Paradells, and Jon Crowcroft in [LPWAN-GAP]. Additional text from that document is also used elsewhere above. The full list of contributors is as follows: Jon Crowcroft University of Cambridge JJ Thomson Avenue Cambridge, CB3 0FD United Kingdom Email: Carles Gomez UPC/i2CAT C/Esteve Terradas, 7 Castelldefels 08860 Spain Email:
Top   ToC   RFC8376 - Page 41
      Bob Heile
      Wi-Sun Alliance
      11 Robert Toner Blvd, Suite 5-301
      North Attleboro, MA  02763
      United States of America

      Phone: +1-781-929-4832

      Ana Minaburo
      2bis rue de la Chataigneraie
      35510 Cesson-Sevigne Cedex


      Josep PAradells
      C/Jordi Girona, 1-3
      Barcelona 08034


      Charles E. Perkins
      2330 Central Expressway
      Santa Clara, CA 95050
      United States of America


      Benoit Ponsard
      425 rue Jean Rostand
      Labege  31670

Top   ToC   RFC8376 - Page 42
      Antti Ratilainen
      Hirsalantie 11
      Jorvas  02420


      Chin-Sean SUM
      Wi-Sun Alliance
      20, Science Park Rd 117674

      Phone: +65 6771 1011

      Laurent Toutain
      Institut MINES TELECOM ; TELECOM Bretagne
      2 rue de la Chataigneraie
      CS 17607
      35576 Cesson-Sevigne Cedex


      Alper Yegin


      Juan Carlos Zuniga
      425 rue Jean Rostand
      Labege  31670

Top   ToC   RFC8376 - Page 43

Author's Address

Stephen Farrell (editor) Trinity College Dublin Dublin 2 Ireland Phone: +353-1-896-2354 Email: