RFC 8376
Low-Power Wide Area Network (LPWAN) Overview
Pages: 43
Informational
Informational
Part 2 of 2 – Pages 24 to 43
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.
+---------------------------------------------------------------------+ | 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.
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
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.
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
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 <https://datatracker.ietf.org/wg/6lo/> 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
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 compression.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).
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
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 specific. 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.
[etsi_ref1] 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_ref2] 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, <http://standards.ieee.org/develop/regauth/tut/eui.pdf>. [FANOV] IETF, "Wi-SUN Alliance Field Area Network (FAN) Overview", IETF 97, November 2016, <https://www.ietf.org/proceedings/97/slides/ slides-97-lpwan-35-wi-sun-presentation-00.pdf>. [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, <http://www.itu.int/rec/T-REC-G.9959>. [IEEE.802.11] 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.
[IEEE.802.15.12] IEEE, "Upper Layer Interface (ULI) for IEEE 802.15.4 Low- Rate Wireless Networks", IEEE 802.15.12. [IEEE.802.15.4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE 802.15.4, <https://standards.ieee.org/findstds/ standard/802.15.4-2015.html>. [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 1: MAC sublayer", IEEE 802.15.4e. [IEEE.802.15.4g] 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.802.15.9] IEEE, "IEEE Recommended Practice for Transport of Key Management Protocol (KMP) Datagrams", IEEE Standard 802.15.9, 2016, <https://standards.ieee.org/findstds/ standard/802.15.9-2016.html>. [IEEE.802.1AR] ANSI/IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR. [IEEE.802.1x] IEEE, "Port Based Network Access Control", IEEE 802.1x. [LoRaSpec] LoRa Alliance, "LoRaWAN Specification Version V1.0.2", July 2016, <https://lora-alliance.org/sites/default/ files/2018-05/lorawan1_0_2-20161012_1398_1.pdf>. [LoRaWAN] Farrell, S. and A. Yegin, "LoRaWAN Overview", Work in Progress, draft-farrell-lpwan-lora-overview-01, October 2016. [LoRaWAN-AUTH] Garcia, D., Marin, R., Kandasamy, A., and A. Pelov, "LoRaWAN Authentication in Diameter", Work in Progress, draft-garcia-dime-diameter-lorawan-00, May 2016.
[LoRaWAN-RADIUS] Garcia, D., Lopez, R., Kandasamy, A., and A. Pelov, "LoRaWAN Authentication in RADIUS", Work in Progress, draft-garcia-radext-radius-lorawan-03, May 2017. [LPWAN-GAP] 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, <https://www.rfc-editor.org/info/rfc768>. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <https://www.rfc-editor.org/info/rfc2460>. [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, <https://www.rfc-editor.org/info/rfc2904>. [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, <https://www.rfc-editor.org/info/rfc3095>.
[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, <https://www.rfc-editor.org/info/rfc3315>. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, DOI 10.17487/RFC3963, January 2005, <https://www.rfc-editor.org/info/rfc3963>. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>. [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, <https://www.rfc-editor.org/info/rfc4443>. [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, <https://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, <https://www.rfc-editor.org/info/rfc4944>. [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <https://www.rfc-editor.org/info/rfc5216>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>. [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, <https://www.rfc-editor.org/info/rfc5280>.
[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, <https://www.rfc-editor.org/info/rfc6282>. [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, <https://www.rfc-editor.org/info/rfc6775>. [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, <https://www.rfc-editor.org/info/rfc6961>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>. [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, "Architectural Considerations in Smart Object Networking", RFC 7452, DOI 10.17487/RFC7452, March 2015, <https://www.rfc-editor.org/info/rfc7452>. [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, <https://www.rfc-editor.org/info/rfc7668>. [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, February 2017, <https://www.rfc-editor.org/info/rfc8065>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>. [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, <https://www.rfc-editor.org/info/rfc8240>.
[Sigfox] Zuniga, J. and B. PONSARD, "Sigfox System Description", Work in Progress, draft-zuniga-lpwan-sigfox-system-description-04, December 2017. [TGPP23720] 3GPP, "Study on architecture enhancements for Cellular Internet of Things", 3GPP TS 23.720 13.0.0, 2016. [TGPP33203] 3GPP, "3G security; Access security for IP-based services", 3GPP TS 23.203 13.1.0, 2016. [TGPP36201] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); LTE physical layer; General description", 3GPP TS 36.201 13.2.0, 2016. [TGPP36300] 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, <http://www.3gpp.org/ftp/Specs/2016-09/Rel-14/36_series/>. [TGPP36321] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification", 3GPP TS 36.321 13.2.0, 2016. [TGPP36322] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification", 3GPP TS 36.322 13.2.0, 2016. [TGPP36323] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification (Not yet available)", 3GPP TS 36.323 13.2.0, 2016. [TGPP36331] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification", 3GPP TS 36.331 13.2.0, 2016.
[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 2016. [wisun-pressie1] Beecher, P., "Wi-SUN Alliance", March 2017, <http://indiasmartgrid.org/event2017/10-03-2017/4.%20Round table%20on%20Communication%20and%20Cyber%20Security/1.%20P hil%20Beecher.pdf>. [wisun-pressie2] Heile, B., "Wi-SUN Alliance Field Area Network (FAN)Overview", As presented at IETF 97, November 2016, <https://www.ietf.org/proceedings/97/slides/ slides-97-lpwan-35-wi-sun-presentation-00.pdf>.Acknowledgments
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 (arun@acklio.com) 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 <https://connectcentre.ie/pervasive-nation/>.
Contributors
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: jon.crowcroft@cl.cam.ac.uk Carles Gomez UPC/i2CAT C/Esteve Terradas, 7 Castelldefels 08860 Spain Email: carlesgo@entel.upc.edu
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
Email: bheile@ieee.org
Ana Minaburo
Acklio
2bis rue de la Chataigneraie
35510 Cesson-Sevigne Cedex
France
Email: ana@ackl.io
Josep PAradells
UPC/i2CAT
C/Jordi Girona, 1-3
Barcelona 08034
Spain
Email: josep.paradells@entel.upc.edu
Charles E. Perkins
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: charliep@computer.org
Benoit Ponsard
Sigfox
425 rue Jean Rostand
Labege 31670
France
Email: Benoit.Ponsard@sigfox.com
URI: http://www.sigfox.com/
Antti Ratilainen
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: antti.ratilainen@ericsson.com
Chin-Sean SUM
Wi-Sun Alliance
20, Science Park Rd 117674
Singapore
Phone: +65 6771 1011
Email: sum@wi-sun.org
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
Alper Yegin
Actility
Paris
France
Email: alper.yegin@actility.com
Juan Carlos Zuniga
Sigfox
425 rue Jean Rostand
Labege 31670
France
Email: JuanCarlos.Zuniga@sigfox.com
URI: http://www.sigfox.com/
Author's Address
Stephen Farrell (editor) Trinity College Dublin Dublin 2 Ireland Phone: +353-1-896-2354 Email: stephen.farrell@cs.tcd.ie