RFC 9453

Applicability and Use Cases for IPv6 over Networks of Resource-constrained Nodes (6lo)

๐Ÿ“… published September 2023, from ietf

RFC 9453 ๐ŸŽ€

Applicability and Use Cases for IPv6 over Networks of Resource-constrained Nodes (6lo)

๐Ÿ’– Bestie, this is part 1 of 7. It covers the title block, the front matter, the TOC, and sections 1 through 2.3. More parts are coming!
  • Publisher: Internet Engineering Task Force (IETF) ๐ŸŒธ
  • Request for Comments: 9453
  • Category: Informational (not a Standards Track spec, just here to teach us stuff ๐Ÿงš)
  • ISSN: 2070-1721
  • Date: September 2023
  • Obsoletes / Updates: the header doesn't list any Obsoletes or Updates, so this doc doesn't replace or update anything ๐Ÿฆ‹

Authors:

  • Y-G. Hong, Daejeon University
  • C. Gomez, UPC
  • Y. Choi, ETRI
  • A. Sangi, Wenzhou-Kean University
  • S. Chakrabarti, Verizon

Abstract

okay so this doc is all about where IPv6 over constrained-node networks (6lo) actually makes sense, plus some real-life deployment examples ๐Ÿ’… It's giving practical, not theory-only. Besides IEEE Std 802.15.4, it looks at a bunch of other link-layer techs too: ITU-T G.9959 (Z-Wave), Bluetooth Low Energy (Bluetooth LE), Digital Enhanced Cordless Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near Field Communication (NFC), and Power Line Communication (PLC). The target audience? Anyone who wants to understand and evaluate running end-to-end IPv6 over constrained-node networks, whether for local stuff or for Internet connectivity ๐ŸŒˆ

Status of This Memo

This document is not an Internet Standards Track specification. It's published for informational purposes ๐Ÿ“š

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that ๐Ÿซถ

For info about the current status of this document, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9453.

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. ๐Ÿ”’

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License โš–๏ธ

Table of Contents

1.  Introduction
2.  6lo Link-Layer Technologies
  2.1.  ITU-T G.9959
  2.2.  Bluetooth LE
  2.3.  DECT-ULE
  2.4.  MS/TP
  2.5.  NFC
  2.6.  PLC
  2.7.  Comparison between 6lo Link-Layer Technologies
3.  Guidelines for Adopting an IPv6 Stack (6lo)
4.  6lo Deployment Examples
  4.1.  Wi-SUN Usage of 6lo in Network Layer
  4.2.  Thread Usage of 6lo in the Network Layer
  4.3.  G3-PLC Usage of 6lo in Network Layer
  4.4.  Netricity Usage of 6lo in the Network Layer
5.  6lo Use-Case Examples
  5.1.  Use Case of ITU-T G.9959: Smart Home
  5.2.  Use Case of Bluetooth LE: Smartphone-Based Interaction
  5.3.  Use Case of DECT-ULE: Smart Home
  5.4.  Use Case of MS/TP: Building Automation Networks
  5.5.  Use Case of NFC: Alternative Secure Transfer
  5.6.  Use Case of PLC: Smart Grid
6.  IANA Considerations
7.  Security Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Appendix A.  Design Space Dimensions for 6lo Deployment
Acknowledgements
Authors' Addresses

1. Introduction โœจ

okay so running IPv6 on constrained-node networks is a whole vibe, and not the easy kind ๐Ÿ˜ญ These networks come with stuff like small packets, low power, low bandwidth, and tons of devices, among other things [RFC4919] [RFC7228]. For example, lots of IEEE Std 802.15.4 variants [IEEE-802.15.4] have a frame size of 127 octets, but IPv6 needs its underlying layer to support an MTU of 1280 bytes. Yikes! ๐Ÿ™ˆ Those 802.15.4 variants also don't offer fragmentation and reassembly. (Fun fact: IEEE Std 802.15.9-2021 gives the IEEE Std 802.15.4 a multiplexing and fragmentation layer [IEEE-802.15.9].) So an adaptation layer that handles fragmentation and reassembly must be provided below IPv6. And since the frame size is so tiny and energy use has to be low, we also need packet header compression. It's all connected ๐Ÿ”—

The IETF IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Working Group put out a suite of specs that makes an adaptation layer for IPv6 over IEEE Std 802.15.4. It covers these things:

  • fragmentation and reassembly, address autoconfiguration, and a frame format [RFC4944]
  • IPv6 (and UDP) header compression [RFC6282]
  • Neighbor Discovery Optimization for 6LoWPAN [RFC6775] [RFC8505]

IoT services are getting more popular, and the IETF has defined adaptation layer stuff to support IPv6 over link-layer techs other than IEEE Std 802.15.4 ๐ŸŒŸ Think Bluetooth Low Energy (Bluetooth LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near Field Communication (NFC), and Power Line Communication (PLC). The 6lo adaptation layers basically take a variation of the 6LoWPAN stack and apply it to each specific link-layer tech.

The 6LoWPAN Working Group also made "Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6568], which describes possible application scenarios and use cases for LoWPANs. This doc is here for people who are new to the IPv6 over constrained-node networks (6lo) concept and want to figure out whether it fits the constrained-node network they care about ๐Ÿฆ‹ It walks through a few sets of practical 6lo deployment scenarios and use-case examples. It also looks at a bunch of network design space dimensions, like Deployment, Network Size, Power Source, Connectivity, Multi-Hop Communication, Traffic pattern, Mobility, and QoS requirements (see Appendix A).

This document covers the applicability and use cases of 6lo, looking at these aspects:

  • Various IoT-related wired or wireless link-layer technologies, with practical info about each one.
  • General guidelines on how the 6LoWPAN stack can be modified for a given L2 technology.
  • Various 6lo use cases and practical deployment examples.

Quick note: the words "master" and "slave" are kept in this document, because that's how the industry uses them (e.g., [TIA-485-A] and [BACnet]) ๐Ÿง

2.1. ITU-T G.9959

The ITU-T G.9959 Recommendation [G.9959] targets LoWPANs and defines physical-layer and link-layer functionality. It supports physical layers of 9.6 kbit/s, 40 kbit/s, and 100 kbit/s ๐Ÿ’ซ [G.9959] also defines how a unique 32-bit HomeID network identifier gets assigned by a network controller, and how an 8-bit NodeID host identifier gets allocated to each node. NodeIDs are unique within the network that the HomeID identifies. The G.9959 HomeID represents an IPv6 subnet, which is identified by one or more IPv6 prefixes [RFC7428]. ITU-T G.9959 works for smart home applications, and the transmission range is 100 meters per hop ๐Ÿ 

2.2. Bluetooth LE

Bluetooth LE got introduced in Bluetooth 4.0, got an upgrade in Bluetooth 4.1, and kept developing through later versions ๐Ÿ’™ Its data rates are 125 kb/s, 500 kb/s, 1 Mb/s, and 2 Mb/s, and the max transmission range is around 100 meters (outdoors). The Bluetooth Special Interest Group (Bluetooth SIG) also published the Internet Protocol Support Profile (IPSP). The IPSP lets you discover IP-enabled devices and set up link-layer connections for carrying IPv6 packets. IPv6 over Bluetooth LE depends on both Bluetooth 4.1 [BTCorev5.4] and IPSP 1.0 [IPSP] or newer โœจ

Tons of devices like mobile phones, notebooks, tablets, and other handheld computers that support Bluetooth 4.0 or later also support the low-energy version of Bluetooth. Bluetooth LE is also showing up in lots of accessories that work with mobile devices ๐Ÿ“ฑ For example, a heart rate monitor can send its data through the mobile phone to a server on the Internet [RFC7668]. The typical use of Bluetooth LE is smartphone-based interaction with constrained devices. Originally, Bluetooth LE was designed for star topology networks. But newer Bluetooth versions can form extended topologies, and IPv6 support for mesh networks of Bluetooth LE devices has been developed [RFC9159] ๐Ÿ•ธ๏ธ

2.3. DECT-ULE

DECT-ULE is a low-power air interface tech built to support both circuit-switched services, like voice calls, and packet-mode data services at a modest data rate [TS102.939-1] [TS102.939-2] ๐Ÿ“ž

The DECT-ULE protocol stack has a physical layer that operates at frequencies in the dedicated 1880 - 1920 MHz band (it depends on the region), and it uses a symbol rate of 1.152 Mbps. Radio bearers are allocated using Frequency-Division Multiplex (FDMA), Time-Division Multiple Access (TDMA), and Time-Division Duplex (TDD) techniques. The coverage distance runs from 70 meters (indoors) to 600 meters (outdoors) ๐Ÿ“ก

In its generic network topology, DECT is defined as a cellular network technology. But the most common setup is a star network, with a single Fixed Part (FP) defining the network and a number of Portable Parts (PPs) attached to it ๐ŸŒŸ The Medium Access Control (MAC) layer supports classical DECT, which is used for services like discovery, pairing, and security features. All of these features were reused from DECT.

A DECT-ULE device can switch to the ULE mode of operation, which uses the new Ultra Low Energy (ULE) MAC layer features ๐Ÿ”‹ The DECT-ULE Data Link Control (DLC) provides multiplexing, plus segmentation and re-assembly for larger packets coming from layers above. The DECT-ULE layer also does per-message authentication and encryption ๐Ÿ” The DLC layer makes sure packet integrity holds and packet order is preserved, but delivery is best effort.

The current DECT-ULE MAC layer standard supports low-bandwidth data broadcast. But the broadcast service hasn't been standardized for higher layers yet [RFC8105]. DECT-ULE can be used for smart metering in a home ๐Ÿ“

2.4. MS/TP โœจ

okay bestie, MS/TP is a MAC protocol for the RS-485 [TIA-485-A] physical layer, and it's mostly used in building automation networks ๐Ÿข๐Ÿ’…

An MS/TP device is usually built on a low-cost microcontroller with limited processing power and memory ๐Ÿค These limits, plus low data rates and a small MAC address space, are giving the same vibes as 6LoWPAN networks ๐Ÿฅน But MS/TP is actually different from 6LoWPAN in at least three big ways:

a. MS/TP devices are typically mains powered ๐Ÿ”Œ

b. All MS/TP devices on a segment can talk to each other directly, so there are no hidden node issues or mesh routing issues ๐Ÿ™Œ

c. The latest MS/TP spec supports large payloads, so you don't need fragmentation and reassembly below IPv6 ๐ŸŽ€

MS/TP is designed for multidrop networks over shielded twisted pair wiring ๐Ÿงต It can support network segments up to 1000 meters long at a data rate of 115.2 kbit/s, or up to 1200 meters at lower bit rates ๐Ÿ“ An MS/TP interface only needs a Universal Asynchronous Receiver Transmitter (UART), an RS-485 [TIA-485-A] transceiver with a driver that can be disabled, and a 5 ms resolution timer โฑ๏ธ The MS/TP MAC is typically implemented in software ๐Ÿ’ป

Because of its long range (~1 km), MS/TP can connect remote devices (like district heating controllers) to the nearest building control infrastructure over a single link [RFC8163] ๐ŸŒธ

2.5. NFC ๐Ÿ“ฑ

NFC tech enables secure interactions between electronic devices ๐Ÿ” It lets consumers do contactless transactions, access digital content, and connect devices with a single touch [LLCP-1.4] ๐Ÿ‘† The distance between sender and receiver is 10 cm or less ๐Ÿ“ NFC complements lots of popular consumer wireless technologies by using the key elements of existing standards for contactless card technology ๐Ÿ’ณ

Extending what contactless card tech can do, NFC also lets devices share information at a distance of less than 10 cm, with a maximum communication speed of 424 kbps โšก Users can share business cards, make transactions, grab info from a smart poster, or provide credentials for access control systems with just a simple touch ๐Ÿซถ

NFC's bidirectional communication is perfect for connecting with other technologies, since the connection is as easy as a touch ๐Ÿงฒ On top of easy connections and quick transactions, simple data sharing is available too [RFC9428] ๐Ÿฆ‹ NFC can be used for secure transfer services where privacy matters ๐Ÿ”’โœจ

2.6. PLC ๐ŸŒˆ

PLC is a data transmission technique that uses power conductors as the medium [RFC9354] โšก Unlike other dedicated communication infrastructure, power conductors are widely available both indoors and outdoors ๐Ÿ  Plus, wired tech causes less interference to the radio medium than wireless tech does, and it's more reliable than wireless counterparts ๐Ÿ’œ

The table below shows some available open standards that define PLC ๐Ÿ“‹

+=============+=================+============+===========+==========+
| PLC Systems | Frequency Range |    Type    |    Data   | Distance |
|             |                 |            |    Rate   |          |
+=============+=================+============+===========+==========+
|  IEEE 1901  |    < 100 MHz    | Broadband  |    200    |  1000 m  |
|             |                 |            |    Mbps   |          |
+-------------+-----------------+------------+-----------+----------+
| IEEE 1901.1 |     < 12 MHz    |  PLC-IoT   |     10    |  2000 m  |
|             |                 |            |    Mbps   |          |
+-------------+-----------------+------------+-----------+----------+
| IEEE 1901.2 |    < 500 kHz    | Narrowband |    200    |  3000 m  |
|             |                 |            |    kbps   |          |
+-------------+-----------------+------------+-----------+----------+
|    G3-PLC   |    < 500 kHz    | Narrowband |    234    |  3000 m  |
|             |                 |            |    kbps   |          |
+-------------+-----------------+------------+-----------+----------+

               Table 1: Some Available Open Standards in PLC

IEEE Std 1901 [IEEE-1901] defines a broadband variant of PLC, but it is only effective within short range ๐Ÿ“‰ This standard addresses the requirements of high data rates, like the Internet, HDTV, audio, and gaming ๐ŸŽฎ

IEEE Std 1901.1 [IEEE-1901.1] defines a medium frequency band (less than 12 MHz) broadband PLC technology for smart grid applications, based on Orthogonal Frequency Division Multiplexing (OFDM) ๐ŸŒ€ By achieving an extended communication range with medium speeds, this standard can be applied both indoors and outdoors, like Advanced Metering Infrastructure (AMI), street lighting, electric vehicle charging, and smart cities ๐Ÿ™๏ธ

IEEE Std 1901.2 [IEEE-1901.2] defines a narrowband variant of PLC with a lower data rate but a significantly higher transmission range, which could be used indoors or even outdoors ๐ŸŒค๏ธ A typical use case of PLC is a smart grid โšก

G3-PLC [G3-PLC] is a narrowband PLC technology based on the ITU-T G.9903 Recommendation [G.9903] ๐Ÿ“– The ITU-T G.9903 Recommendation contains the physical layer and data link-layer specification for the G3-PLC narrowband OFDM power line communication transceivers, for communications over alternating current and direct current electric power lines in frequency bands below 500 kHz ๐Ÿง 

In the subsections above, we went through various 6lo link-layer technologies ๐Ÿซง The table below shows the dominant parameters of each use case for each 6lo link-layer technology ๐Ÿ‘€

+=========+========+===========+========+========+========+=========+
|         | Z-Wave | Bluetooth |DECT-ULE| MS/TP  |  NFC   |   PLC   |
|         |        |     LE    |        |        |        |         |
+=========+========+===========+========+========+========+=========+
|  Usage  |  Home  |  Interact | Meter  |Building| Secure |  Smart  |
|         | Autom. |  w/ Smart |Reading | Autom. |Transfer|   Grid  |
|         |        |   Phone   |        |        |        |         |
+=========+--------+-----------+--------+--------+--------+---------+
| Topology|L2-mesh |   Star &  | Star,  | MS/TP, |  P2P,  |Star Tree|
|    &    |   or   |    Mesh   |No mesh |No mesh |L2-mesh |   Mesh  |
|  Subnet |L3-mesh |           |        |        |        |         |
+=========+--------+-----------+--------+--------+--------+---------+
| Mobility|   No   |    Yes    |   No   |   No   |  Yes   |    No   |
|   Req.  |        |           |        |        |        |         |
+=========+--------+-----------+--------+--------+--------+---------+
|Buffering|  Yes   |    Yes    |  Yes   |  Yes   |  Yes   |   Yes   |
|   Req.  |        |           |        |        |        |         |
+=========+--------+-----------+--------+--------+--------+---------+
| Latency,|  Yes   |    Yes    |  Yes   |  Yes   |  Yes   |   Yes   |
| QoS Req.|        |           |        |        |        |         |
+=========+--------+-----------+--------+--------+--------+---------+
| Frequent|   No   |     No    |   No   |  Yes   |   No   |    No   |
| Tx Req. |        |           |        |        |        |         |
+=========+--------+-----------+--------+--------+--------+---------+
|   RFC   |RFC 7428|  RFC 7668 |RFC 8105|RFC 8163|RFC 9428| RFC 9354|
|         |        |  RFC 9159 |        |        |        |         |
+=========+--------+-----------+--------+--------+--------+---------+

          Table 2: Comparison between 6lo Link-Layer Technologies

3. Guidelines for Adopting an IPv6 Stack (6lo) โœจ

okay bestie, 6lo's whole thing is reusing and adapting existing 6LoWPAN stuff ๐Ÿงš so IPv6 can run efficiently over a bunch of IoT L2 technologies ๐Ÿ’–. This guideline is for new constrained L2 techs that might end up running a modified 6LoWPAN stack on top. The modification should be based on the following:

Addressing Model:

The addressing model decides whether the device can form IPv6 link-local and global addresses ๐Ÿฆ‹, and what the best way is to derive IPv6 addresses for constrained L2 devices. IPv6 addresses derived from an L2 address are specified in [RFC4944], but privacy gets messy ๐Ÿ™ˆ because the L2 address in 6lo link-layer techs is kinda short, so devices can become vulnerable to various threats. For global usage, a unique IPv6 address must be derived using an assigned prefix and a unique interface ID. [RFC8065] gives you guidelines for that. For MAC-derived IPv6 addresses, check [RFC8163] for mapping examples. Broadcast and multicast support depend on the L2 network. Most low-power L2 implementations map multicast to broadcast networks, so be careful about when you use broadcast, and try to stick to unicast whenever possible ๐Ÿซถ.

MTU Considerations:

The deployment should consider packet maximum transmission unit (MTU) needs over the link layer, and should consider whether fragmentation and reassembly of packets are needed at the 6LoWPAN layer. For example, if the link layer supports fragmentation and reassembly, then the 6LoWPAN layer may not need to support fragmentation and reassembly. Honestly, for the greatest efficiency, a low-power link layer that can carry unfragmented application packets would be optimal for packet transmission, if the deployment can afford it ๐Ÿ‘‘. Check out 6lo RFCs [RFC7668], [RFC8163], and [RFC8105] for example guidance.

Mesh or L3 Routing:

6LoWPAN specs provide mechanisms to support mesh routing at L2, a configuration called "mesh-under" [RFC6606]. It's also possible to use an L3 routing protocol in 6LoWPAN, an approach known as "route-over". [RFC6550] defines RPL, an L3 routing protocol for low-power and lossy networks using directed acyclic graphs. 6LoWPAN is routing-protocol-agnostic ๐Ÿ’…, so it doesn't specify any particular L2 or L3 routing protocol to use with a 6LoWPAN stack.

Address Assignment:

6LoWPAN developed a new version of IPv6 Neighbor Discovery [RFC4861] [RFC4862]. 6LoWPAN Neighbor Discovery [RFC6775] [RFC8505] inherits from IPv6 Neighbor Discovery for mechanisms like Stateless Address Autoconfiguration (SLAAC) and Neighbor Unreachability Detection (NUD). A 6LoWPAN node is also expected to be an IPv6 host per [RFC8200], which means it should ignore consumed routing headers and hop-by-hop options. When operating in an RPL network [RFC6550], it's also beneficial to support IP-in-IP encapsulation [RFC9008]. The 6LoWPAN node should also support the registration extensions defined in [RFC8505] and use the mechanism as the default Neighbor Discovery method. It is the responsibility of the deployment to ensure unique global IPv6 addresses for Internet connectivity. For local-only connectivity, IPv6 Unique Local Address (ULA) may be used. [RFC6775] and [RFC8505] specify the 6LoWPAN Border Router (6LBR), which is responsible for prefix assignment to the 6LoWPAN network. A 6LBR can be connected to the Internet or to an enterprise network via one of the interfaces. Check [RFC7668] and [RFC8105] for examples of address assignment considerations. In addition, privacy considerations in [RFC8065] must be consulted for applicability. In certain scenarios, the deployment may not support IPv6 address autoconfiguration due to regulatory and business reasons, and may choose to offer a separate address assignment service. Address-Protected Neighbor Discovery [RFC8928] enables source address validation [RFC6620] and protects the address ownership against impersonation attacks ๐Ÿ”.

Broadcast Avoidance:

6LoWPAN Neighbor Discovery aims to reduce the amount of multicast traffic of classic Neighbor Discovery, since IP-level multicast translates into L2 broadcast in many L2 technologies [RFC6775]. It relies on a proactive registration to avoid using multicast for address resolution. It also uses a unicast method for Duplicate Address Detection (DAD), and avoids multicast lookups from all nodes by using non-onlink prefixes. Router Advertisements (RAs) are also sent in unicast, in response to Router Solicitations (RSs) ๐ŸŒธ.

Host-to-Router Interface:

6lo has defined registration extensions for 6LoWPAN Neighbor Discovery [RFC8505]. This effort provides a host-to-router interface, so a host can ask its router to ensure reachability for the address it registered with the router. Note that functionality has been developed so that such a host can benefit from routing services in an RPL network [RFC9010] ๐Ÿ›ฐ๏ธ.

Proxy Neighbor Discovery:

Further functionality also allows a device (e.g., an energy-constrained device that needs to sleep most of the time) to request proxy Neighbor Discovery services from a 6LoWPAN Backbone Router (6BBR) [RFC8505] [RFC8929]. The latter RFC federates a number of links into a multi-link subnet ๐Ÿฆ‹.

Header Compression:

IPv6 header compression [RFC6282] is a vital part of IPv6 over low-power communication ๐Ÿ’œ. Examples of header compression over different link-layer specifications are found in [RFC7668], [RFC8163], and [RFC8105]. A generic header compression technique is specified in [RFC7400]. For 6LoWPAN networks where RPL is the routing protocol, there are 6LoWPAN header compression extensions that allow compressing the RPL artifacts used when forwarding packets in the route-over mesh [RFC8138] [RFC9035].

Security and Encryption:

Okay, this one is serious ๐Ÿšจ. Although 6LoWPAN basic specifications do not address security at the network layer, the assumption is that L2 security must be present. Nevertheless, care must be taken, since specific L2 technologies may exhibit security gaps. Typically, 6lo L2 technologies (see Section 2) offer security properties such as confidentiality and/or message authentication. In addition, end-to-end security is highly desirable. Protocols such as DTLS/TLS, as well as Object Security, are being used in the constrained-node network domain [SEC-PROT-COMP]. The relevant IETF working groups should be consulted for application and transport level security. The IETF has worked on address authentication [RFC8928], and secure bootstrapping is also being discussed in the IETF. However, there may be other security mechanisms available in a deployment through other standards, such as hardware-level security or certificates for the initial booting process. In order to use security mechanisms, the implementation needs to be able to afford them in terms of processing capabilities and energy consumption โšก.

Additional Processing:

[RFC8066] defines guidelines for ESC dispatch octets used in the 6LoWPAN header. The ESC type is defined to use additional dispatch octets in the 6LoWPAN header. An implementation may take advantage of the ESC header to offer deployment-specific processing of 6LoWPAN packets ๐Ÿงฉ.

4. 6lo Deployment Examples ๐ŸŒˆ

4.1. Wi-SUN Usage of 6lo in Network Layer ๐Ÿ“

Wireless Smart Ubiquitous Network (Wi-SUN) [Wi-SUN] is a technology based on IEEE Std 802.15.4g [IEEE-802.15.4]. Wi-SUN networks support star and mesh topologies, as well as hybrid star/mesh deployments, but these are typically laid out in a mesh topology where each node relays data for the network to provide network connectivity ๐Ÿ•ธ๏ธ. Wi-SUN networks are deployed on both grid-powered and battery-operated devices [RFC8376].

The main application domains using Wi-SUN are smart utility and smart city networks. The Wi-SUN Alliance Field Area Network (FAN) primarily covers outdoor networks. The Wi-SUN FAN specification defines an IPv6-based protocol suite that includes TCP/UDP, IPv6, 6lo adaptation layer, DHCPv6 for IPv6 address management, RPL, and ICMPv6 ๐ŸŒŸ.

4.2. Thread Usage of 6lo in the Network Layer ๐Ÿ 

Thread is an IPv6-based networking protocol stack built on open standards, designed for smart home environments, and based on low-power IEEE Std 802.15.4 mesh networks. Because of its IPv6 foundation, Thread can support existing popular application layers and IoT platforms, provide end-to-end security, ease development, and enable flexible designs [Thread] ๐Ÿ’–.

The Thread specification uses the IEEE Std 802.15.4 [IEEE-802.15.4] physical and MAC layers, operating at 250 kbps in the 2.4 GHz band.

Thread devices use 6LoWPAN, as defined in [RFC4944] and [RFC6282], for transmission of IPv6 packets over IEEE Std 802.15.4 networks. Header compression is used within the Thread network, and devices transmitting messages compress the IPv6 header to minimize the size of the transmitted packet. The mesh header is supported for link-layer (i.e., mesh-under) forwarding. The mesh header as used in Thread also allows efficient end-to-end fragmentation of messages, rather than the hop-by-hop fragmentation specified in [RFC4944]. Mesh-under routing in Thread is based on a distance vector protocol in a full mesh topology ๐Ÿฆ‹.

4.3. G3-PLC Usage of 6lo in Network Layer โšก

G3-PLC [G3-PLC] is a narrowband PLC technology that is based on the ITU-T G.9903 Recommendation [G.9903]. G3-PLC supports multi-hop mesh network topology and facilitates highly reliable, long-range communication. With the abilities to support IPv6 and to cross transformers, G3-PLC is regarded as one of the next-generation narrowband PLC technologies. G3-PLC has got massive deployments over several countries, e.g., Japan and France ๐Ÿ‡ฏ๐Ÿ‡ต๐Ÿ‡ซ๐Ÿ‡ท.

The main application domains using G3-PLC are smart grid and smart cities. This includes, but is not limited to, the following applications:

  • smart metering
  • vehicle-to-grid communication
  • demand response
  • distribution automation
  • home/building energy management systems
  • smart street lighting
  • AMI backbone network
  • wind/solar farm monitoring

In the G3-PLC specification, the 6lo adaption layer utilizes the 6LoWPAN functions (e.g., header compression, fragmentation, and reassembly). However, due to the different characteristics of the PLC media, the 6LoWPAN adaptation layer cannot perfectly fulfill the requirements [RFC9354]. The ESC dispatch type is used in G3-PLC to provide fundamental mesh routing and bootstrapping functionalities [RFC8066] ๐Ÿงš.

4.4. Netricity Usage of 6lo in the Network Layer

okay so Netricity is the HomePlug Powerline Alliance's program [NETRICITY] pushing products built on the IEEE Std 1901.2 low-frequency narrowband PLC standard [IEEE-1901.2] ๐Ÿ”Œโœจ. It's all about urban and long-distance comms that can travel through the transformers of the distribution network, using frequencies below 500 kHz. And it's giving privacy and secure networks too ๐Ÿ”๐Ÿ’œ

The big applications here are smart grid and smart cities ๐Ÿ™๏ธโšก The list goes on, but the highlights are:

  • utility grid modernization
  • distribution automation
  • meter-to-grid connectivity
  • microgrids
  • grid sensor communications
  • load control
  • demand response
  • net metering
  • street lighting control
  • photovoltaic panel monitoring

The Netricity architecture is built on the physical and MAC layers of IEEE Std 1901.2 ๐Ÿงฑ For the 6lo adaptation layer and the IPv6 network layer, it runs the whole IPv6 suite: 6lo/6LoWPAN header compression, DHCPv6 for IP address management, the RPL routing protocol, ICMPv6, and unicast/multicast forwarding ๐ŸŒˆ ngl that's a full kit.

Also, the L3 routing in Netricity uses RPL in non-storing mode, with MRHOF (Minimum Rank with Hysteresis Objective Function) running on their own defined Estimated Transmission Time (ETT) metric ๐Ÿง ๐Ÿ’…

5. 6lo Use-Case Examples

okay now for the fun part ๐ŸŽ€ IPv6 stacks for constrained-node networks use a variation of the 6LoWPAN stack that gets applied to each link-layer technology, so there are lots of different 6lo use cases. This section walks through several of them, each based on a different link-layer technology ๐Ÿฆ‹

5.1. Use Case of ITU-T G.9959: Smart Home

bestie, Z-Wave is one of the main technologies behind smart homes ๐Ÿ ๐Ÿ’– It started out as a proprietary tech that was built specifically for this use case. Recently though, the Z-Wave radio interface (the physical and MAC layers) got standardized as the ITU-T G.9959 specification [G.9959] ๐ŸŽ‰

Example: Use of ITU-T G.9959 for Home Automation

   A variety of home devices (e.g., light dimmers/switches, plugs,
   thermostats, blinds/curtains, and remote controls) are augmented
   with ITU-T G.9959 interfaces.  A user may turn home appliances on
   and off, or the user may control them by pressing a wall switch or
   a button on a remote control.  Scenes may be programmed so that
   the home devices adopt a specific configuration after a given
   event.  Sensors may also periodically send measurements of several
   parameters (e.g., gas presence, light, temperature, humidity),
   which are collected at a sink device, or may generate commands for
   actuators (e.g., a smoke sensor may send an alarm message to a
   safety system).

The devices in that scenario are nodes of a mesh network ๐Ÿ•ธ๏ธ Mesh is so good for this because it gives path diversity, which helps handle indoor multipath propagation issues ๐Ÿ™Œ And since the multi-hop approach lets you reach end-to-end when direct range isn't possible, it's a total win ๐ŸŒธ

5.2. Use Case of Bluetooth LE: Smartphone-Based Interaction

the reason Bluetooth LE is so ๐Ÿ”ฅ right now is that it's supported by a huge majority of smartphones on the market ๐Ÿ“ฑ It lets a smartphone talk to nearby sensors or actuators, and Bluetooth LE is also the main radio interface you'll find in wearables โŒš Since phones usually have other radios that give Internet access, like Wi-Fi or cellular, a phone can act as a gateway for nearby stuff like sensors, actuators, or wearables. You'll see Bluetooth LE in healthcare, sports/wellness, and home automation too ๐Ÿ’œ

Example: Use of a Body Area Network Based on Bluetooth LE for Fitness

   A person wears a smartwatch for fitness purposes.  The smartwatch
   has several sensors (e.g., heart rate, accelerometer, gyrometer,
   GPS, and temperature), a display, and a Bluetooth LE radio
   interface.  The smartwatch can show fitness-related statistics on
   its display.  However, when a paired smartphone is in range of the
   smartwatch, the latter can report almost real-time measurements of
   its sensors to the smartphone, which can forward the data to a
   cloud service on the Internet. 6lo enables this use case by
   providing efficient end-to-end IPv6 support.  In addition, the
   smartwatch can receive notifications (e.g., alarm signals) from
   the cloud service via the smartphone.  On the other hand, the
   smartphone may locally generate messages for the smartwatch, such
   as e-mail reception or calendar notifications.

Other devices can join in too, like on-body sensors, wireless headsets, or head-mounted displays ๐ŸŽง๐Ÿฅฝ They all connect to the smartphone, which makes a star topology with the phone in the middle ๐Ÿ‘‘ Extended topologies (e.g., mesh networks) are still being developed as of when this document was written ๐Ÿ› ๏ธ

5.3. Use Case of DECT-ULE: Smart Home

DECT is hugely popular for wireless phone calls at home โ˜Ž๏ธ๐ŸŒท DECT-ULE is its low-power variant, so it can hook up constrained devices like sensors and actuators to a Fixed Part (FP), which is basically the base station for wireless phones. In this setup the FP also needs a data network connection ๐ŸŒ That makes DECT-ULE a great fit for the connected home, in things like home automation, smart metering, safety, and healthcare ๐Ÿก๐Ÿ’• And because DECT-ULE uses dedicated bandwidth, it avoids the coexistence issues that other techs run into when they share ISM (Industrial, Scientific, and Medical) frequency bands ๐Ÿ™…โ€โ™€๏ธ

Example: Use of DECT-ULE for Smart Metering

   The smart electricity meter of a home is equipped with a DECT-ULE
   transceiver.  This device is in the coverage range of the FP of
   the home.  The FP can act as a router connected to the Internet.
   This way, the smart meter can transmit electricity consumption
   readings through the DECT-ULE link with the FP, and the latter can
   forward such readings to the utility company using Wide Area
   Network (WAN) links.  The meter can also receive queries from the
   utility company or from an advanced energy control system
   controlled by the user, which may also be connected to the FP via
   DECT-ULE.

5.4. Use Case of MS/TP: Building Automation Networks

the main use case for IPv6 over MS/TP (6LoBAC) is building automation ๐Ÿข๐Ÿงก [BACnet] is the open, international standard protocol for building automation, and MS/TP is defined in [BACnet] Clause 9 ๐Ÿค“ MS/TP was built as a low-cost, multi-drop field bus to connect the most numerous parts of a building automation network (sensors and actuators) to their controllers. The big deal with 6LoBAC is that it's designed to co-exist with BACnet MS/TP on the same link, which makes it easier for some BACnet networks to eventually move toward end-to-end IPv6 transport protocols ๐Ÿš€ New 6LoBAC applications may pop up in other areas where low cost, long distance, and low latency matter ๐ŸŒˆ BACnet also has other networking options besides MS/TP, like the recently emerged BACnet IP. But that one runs on high-speed Ethernet infrastructure, so it's outside the constrained-node network scope ๐Ÿ™ˆ

Example: Use of 6LoBAC in Building Automation Networks

   The majority of installations for MS/TP are for "terminal" or
   "unitary" controllers, i.e., single zone or room controllers that
   may connect to HVAC or other controls such as lighting or blinds.
   The economics of daisy chaining a single twisted pair between
   multiple devices is often preferred over home-run, Cat-5-style
   wiring.

A multi-zone controller could be an IP router sitting between a classical Ethernet link and several 6LoBAC links, fanning out to multiple terminal controllers ๐Ÿงฉ

MS/TP's distance capabilities (~1 km) are much better than other 6lo media, so it can be used to connect remote devices to the nearest building infrastructure ๐Ÿ—บ๏ธ Think remote pumping or measuring stations with moderate bandwidth needs. They get the low-cost, robust perks of MS/TP over other wired techs like DSL, without the line-of-sight limits or the hop-by-hop latency of a lot of cheap wireless solutions ๐Ÿ’…โœจ

5.5. Use Case of NFC: Alternative Secure Transfer

different apps handle and move all kinds of secured data ๐Ÿ”’ Depending on how sensitive the data is, you can pick a different transfer method ๐Ÿฆ‹

Example: Use of NFC for Secure Transfer in Healthcare Services with Tele-Assistance

   An older adult who lives alone wears one to several wearable 6lo
   devices to measure heartbeat, pulse rate, etc.  Other 6lo devices
   are densely installed at home for movement detection.  A 6LBR at
   home will send the sensed information to a connected healthcare
   center.  Portable base stations with displays may be used to check
   the data at home, as well.  Data is gathered in both periodic and
   event-driven fashion.  In this application, event-driven data can
   be very time critical.  In addition, privacy becomes a serious
   issue in this case, as the sensed data is very personal.

so while the older adult gets audio and video healthcare services from a tele-assistance system over cellular connections ๐Ÿ“ž๐Ÿ’—, they can switch to NFC connections to send their personal sensed data to the tele-assistance. Hackers can overhear the data on the cellular connection, but they cannot gather the personal data over NFC ๐Ÿซถ that's the vibe: keep the sensitive stuff on the NFC lane ๐ŸŒˆ๐Ÿ’œ

5.6. Use Case of PLC: Smart Grid โšก

Okay so the smart grid is basically the big brain of the electricity system ๐Ÿง โšก. It's built by deploying tons of operational and energy-measuring subsystems across an electricity grid, and they all need to talk to each other. It has multiple administrative levels and segments, so connectivity is a whole thing ๐Ÿงฉ. Last mile connectivity happens over the Low-Voltage segment, and connectivity over electricity distribution happens over the High-Voltage segment. Smart grid systems include AMI, Demand Response, Home Energy Management System, and Wide Area Situational Awareness (WASA), among others ๐Ÿ’….

Sure, the smart grid uses other wired and wireless tech too ๐Ÿ™„, but PLC is lowkey iconic here. It gets reliable data communication over electrical power lines that are already there โšก, and the deployment cost can be comparable to wireless. The 6lo-related PLC scenarios mostly live in Low-Voltage PLC networks, with the biggest applications in advanced metering infrastructure, vehicle-to-grid communications, in-home energy management, and smart street lighting ๐Ÿ’ก.

Example: Use of PLC for AMI ๐Ÿ 

Household electricity meters send time-based data about electric power consumption through PLC ๐Ÿ“Š. Data concentrators collect all the meter data in their living districts, then send it to the Meter Data Management System over a WAN network (for example Medium-Voltage PLC, Ethernet, or General Packet Radio Service (GPRS)) for storage and analysis. Two-way communications are enabled, which means smart meters can do things like notify about electricity charges based on commands from the utility company ๐Ÿซถ.

Using the existing power line infrastructure as the communication medium means building the PLC network naturally saves costs, and labor and operational costs can be minimized from a long-term perspective ๐Ÿ’ธ. This AMI application also speeds up electricity charging, reduces losses by restraining power theft, and helps manage the health of the grid based on line loss analysis. Main character energy for the grid, honestly ๐Ÿ‘‘.

Example: Use of PLC (IEEE Std 1901.1) for WASA in a Smart Grid ๐ŸŒ

Lots of smart grid subsystems only need low data rates, and narrowband variants (e.g., IEEE Std 1901.1) of PLC fulfill those needs ๐Ÿข. Recently though, more complex scenarios are popping up that require higher data rates ๐Ÿ“ˆ.

A WASA subsystem is a great example of this. It collects large amounts of information about the current state of the grid over a wide area, from electric substations as well as power transmission lines ๐Ÿ—ผ. The collected feedback is used for monitoring, controlling, and protecting all the subsystems. It's giving protector energy ๐Ÿ›ก๏ธโœจ.

6. IANA Considerations ๐Ÿ“

This document has no IANA actions. ๐ŸŒธ

7. Security Considerations ๐Ÿ”

Okay bestie, this section is serious, so read it with your whole brain ๐Ÿง ๐Ÿšจ. This document does not create security concerns in addition to those described in the Security Considerations sections of the 6lo adaptation layers considered in this document [RFC7428], [RFC7668], [RFC8105], [RFC8163], [RFC9159], [RFC9428], and [RFC9354].

Neighbor Discovery in 6lo links may be susceptible to threats as detailed in [RFC3756]. Mesh routing is expected to be common in some 6lo networks, such as ITU-T G.9959 networks, Bluetooth LE mesh networks, and PLC networks. That implies additional threats due to ad hoc routing, as per [KW03] ๐Ÿ˜ฌ. Most of the L2 technologies considered in this document (i.e., ITU-T G.9959, Bluetooth LE, DECT-ULE, and PLC) support link-layer security. Making use of those provisions will alleviate the threats mentioned above ๐Ÿ›ก๏ธ. NFC is often considered to offer intrinsic security properties because of its short link range, so note that one ๐Ÿ“ถ. MS/TP does not support link-layer security, since in its original BACnet protocol stack, security is provided at the network layer. So alternative security functionality needs to be used for a 6lo-based protocol stack over MS/TP ๐Ÿšจ๐Ÿ’€.

End-to-end communication is expected to be secured by common mechanisms, such as IPsec, DTLS/TLS, Object Security [RFC8613], and Ephemeral Diffie-Hellman Over COSE (EDHOC) [EDHOC] ๐Ÿ”’โœจ.

The 6lo stack uses the IPv6 addressing model. The implications for privacy and network performance of using L2-address-derived IPv6 addresses need to be considered [RFC8065] ๐Ÿ™ˆ.

8. References ๐Ÿ“š

8.1. Normative References

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

[RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
           Address Autoconfiguration", RFC 4862,
           DOI 10.17487/RFC4862, September 2007,
           <https://www.rfc-editor.org/info/rfc4862>.

[RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
           over Low-Power Wireless Personal Area Networks (6LoWPANs):
           Overview, Assumptions, Problem Statement, and Goals",
           RFC 4919, DOI 10.17487/RFC4919, August 2007,
           <https://www.rfc-editor.org/info/rfc4919>.

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

[RFC6568]  Kim, E., Kaspar, D., and JP. Vasseur, "Design and
           Application Spaces for IPv6 over Low-Power Wireless
           Personal Area Networks (6LoWPANs)", RFC 6568,
           DOI 10.17487/RFC6568, April 2012,
           <https://www.rfc-editor.org/info/rfc6568>.

[RFC6606]  Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
           Statement and Requirements for IPv6 over Low-Power
           Wireless Personal Area Network (6LoWPAN) Routing",
           RFC 6606, DOI 10.17487/RFC6606, May 2012,
           <https://www.rfc-editor.org/info/rfc6606>.

[RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
           Constrained-Node Networks", RFC 7228,
           DOI 10.17487/RFC7228, May 2014,
           <https://www.rfc-editor.org/info/rfc7228>.

[RFC7400]  Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
           IPv6 over Low-Power Wireless Personal Area Networks
           (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
           2014, <https://www.rfc-editor.org/info/rfc7400>.

[RFC7428]  Brandt, A. and J. Buron, "Transmission of IPv6 Packets
           over ITU-T G.9959 Networks", RFC 7428,
           DOI 10.17487/RFC7428, February 2015,
           <https://www.rfc-editor.org/info/rfc7428>.

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

[RFC8105]  Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,
           M., and D. Barthel, "Transmission of IPv6 Packets over
           Digital Enhanced Cordless Telecommunications (DECT) Ultra
           Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
           2017, <https://www.rfc-editor.org/info/rfc8105>.

[RFC8163]  Lynn, K., Ed., Martocci, J., Neilson, C., and S.
           Donaldson, "Transmission of IPv6 over Master-Slave/Token-
           Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
           May 2017, <https://www.rfc-editor.org/info/rfc8163>.

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

[RFC9159]  Gomez, C., Darroudi, S.M., Savolainen, T., and M. Spoerk,
           "IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet
           Protocol Support Profile (IPSP)", RFC 9159,
           DOI 10.17487/RFC9159, December 2021,
           <https://www.rfc-editor.org/info/rfc9159>.

[RFC9354]  Hou, J., Liu, B., Hong, Y-G., Tang, X., and C. Perkins,
           "Transmission of IPv6 Packets over Power Line
           Communication (PLC) Networks", RFC 9354,
           DOI 10.17487/RFC9354, January 2023,
           <https://www.rfc-editor.org/info/rfc9354>.

8.2. Informative References ๐Ÿ“šโœจ

okay bestie, these are the receipts ๐Ÿงพ๐Ÿ’… the extra reading list that backs up the whole vibe, all listed below ๐Ÿซถ

Appendix A. Design Space Dimensions for 6lo Deployment โœจ

Okay so, [RFC6568] is the one that lists the dimensions used to map out the design space of wireless sensor networks for the 6LoWPAN Working Group ๐ŸŒธ The design space is already pretty tight because LoWPANs are low power, short range, and low bit rate, so it's a whole vibe. Section 2 of [RFC6568] describes these design space dimensions: Deployment, Network Size, Power Source, Connectivity, Multi-Hop Communication, Traffic Pattern, Mobility, and Quality of Service (QoS). In this document, though, we're looking at the following dimensions instead ๐Ÿฆ‹

Deployment/Bootstrapping: 6lo nodes can be connected randomly or in an organized manner. Bootstrapping works differently for each link-layer technology ๐Ÿงš

Topology: The topology of 6lo networks can naturally follow the characteristics of each link-layer technology. Point-to-point, star, tree, or mesh topologies can be configured, depending on which link-layer technology you're using ๐Ÿ’œ

L2-mesh or L3-mesh: L2-mesh and L3-mesh can naturally follow the characteristics of each link-layer technology too. Some link-layer technologies support L2-mesh and some don't ๐Ÿ•ธ๏ธ

Multi-link Subnet and Single Subnet: Picking a multi-link subnet or a single subnet depends on connectivity and on how many 6lo nodes there are ๐Ÿ“

Data Rate: 6lo link-layer technologies usually have a low data transmission rate. BUT, by adjusting the MTU, you can get a higher upper-layer data rate. Iconic glow-up ๐Ÿ”ฅ

Buffering Requirements: Some 6lo use cases might need a higher data rate than the link-layer technology can support. In that case, a buffering mechanism, telling the application to throttle how much data it generates, and compression of the data are all options for managing the data ๐Ÿซง

Security and Privacy Requirements: Some 6lo use cases involve moving important and personal data between 6lo nodes. For those, high-level security support is required ๐Ÿ”

Mobility across 6lo Networks and Subnets: How much 6lo nodes move depends on the use case. If the nodes can move or be moved around, a mobility management mechanism is required ๐Ÿšถโ€โ™€๏ธ

Time Synchronization Requirements: Whether the upper-layer service needs time synchronization depends on the use case. For some 6lo health-related use cases, the measured data must be recorded with the exact time โฐ

Reliability and QoS: Some 6lo use cases need high reliability, like real-time or health-related services ๐Ÿ’–

Traffic Patterns: 6lo use cases can involve all kinds of traffic patterns. For example, some need short data lengths with random transmission, while others need continuous or discontinuous data transmission ๐ŸŒˆ

Security Bootstrapping: Without external operations, 6lo nodes must have a security bootstrapping mechanism ๐Ÿ—๏ธ

Power Use Strategy: Some use cases come with requirements on the class of energy availability and on the strategy used for spending power on communication [RFC7228]. Each link-layer technology defines a particular power use strategy that can be tuned [RFC8352]. Readers are expected to be familiar with the terminology found in [RFC7228] ๐Ÿ”‹

Update Firmware Requirements: Most 6lo use cases will need a way to update firmware. In these cases, support for over-the-air updates is required, probably in a broadcast mode when bandwidth is low and there are lots of identical devices ๐Ÿ“ก

Wired vs. Wireless: Plenty of 6lo link-layer technologies are wireless, except MS/TP and PLC. Whether you go wired or wireless mainly depends on the requirements of the 6lo use case and on the characteristics of each kind of technology ๐ŸŽ€

Acknowledgements ๐Ÿซถ

Carles Gomez has been funded in part by the Spanish Government through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P grant, and the PID2019-106808RA-I00 grant ๐Ÿ’… He also got support from Secretaria d'Universitats i Recerca del Departament d'Empresa i Coneixement de la Generalitat de Catalunya through grants 2017 SGR 376 and 2021 SGR 00330. His work on this document was carried out in part during his stay as a visiting scholar at the Computer Laboratory of the University of Cambridge ๐ŸŒธ

Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault, Jianqiang Hou, Kerry Lynn, S.V.R. Anand, and Seyed Mahdi Darroudi gave valuable feedback on this document ๐Ÿ’œ

Das Subir and Michel Veillette shared valuable information about jupiterMesh, and Paul Duffy shared valuable information about Wi-SUN for this document โœจ Jianqiang Hou also shared valuable information about G3-PLC and Netricity ๐Ÿฆ‹ Take Aanstoot, Kerry Lynn, and Dave Robin shared valuable information about MS/TP and a practical MS/TP use case ๐Ÿ“

Deoknyong Ko provided relevant text about LTE-MTC, and shared his experience deploying IPv6 and 6lo technologies over LTE MTC at SK Telecom ๐Ÿงš

Authors' Addresses ๐Ÿ’Œ

Here are the authors, with their contact details exactly as they appear in the original document ๐ŸŒˆ

Yong-Geun Hong

Yong-Geun Hong
Daejeon University
62 Daehak-ro, Dong-gu
Daejeon
34520
South Korea
Phone: +82 42 280 4841
Email: yonggeun.hong@gmail.com

Carles Gomez

Carles Gomez
Universitat Politecnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Email: carles.gomez@upc.edu

Younghwan Choi

Younghwan Choi
ETRI
218 Gajeongno, Yuseong
Daejeon
34129
South Korea
Phone: +82 42 860 1429
Email: yhc@etri.re.kr

Abdur Rashid Sangi

Abdur Rashid Sangi
Wenzhou-Kean University
88 Daxue Road, Ouhai, Wenzhou
Zhejiang
325060
China
Email: sangi_bahrian@yahoo.com

Samita Chakrabarti

Samita Chakrabarti
Verizon
Bedminster, NJ
United States of America
Email: samita.chakrabarti@verizon.com
๐Ÿ“ฆ where this page comes from