+---------------------------------------------------------------------+ | 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.
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]. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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).
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. 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. 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. [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>. https://connectcentre.ie/pervasive-nation/>.
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: email@example.com Carles Gomez UPC/i2CAT C/Esteve Terradas, 7 Castelldefels 08860 Spain Email: firstname.lastname@example.org
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: email@example.com Ana Minaburo Acklio 2bis rue de la Chataigneraie 35510 Cesson-Sevigne Cedex France Email: firstname.lastname@example.org Josep PAradells UPC/i2CAT C/Jordi Girona, 1-3 Barcelona 08034 Spain Email: email@example.com Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara, CA 95050 United States of America Email: firstname.lastname@example.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: email@example.com Chin-Sean SUM Wi-Sun Alliance 20, Science Park Rd 117674 Singapore Phone: +65 6771 1011 Email: firstname.lastname@example.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: email@example.com Juan Carlos Zuniga Sigfox 425 rue Jean Rostand Labege 31670 France Email: JuanCarlos.Zuniga@sigfox.com URI: http://www.sigfox.com/