< draft-ietf-6lo-use-cases-03.txt   draft-ietf-6lo-use-cases-04.txt >
6Lo Working Group Y-G. Hong 6Lo Working Group Y-G. Hong
Internet-Draft ETRI Internet-Draft ETRI
Intended status: Informational C. Gomez Intended status: Informational C. Gomez
Expires: May 3, 2018 UPC/i2cat Expires: September 6, 2018 UPC
Y-H. Choi Y-H. Choi
ETRI ETRI
D-Y. Ko D-Y. Ko
SKtelecom SKtelecom
AR. Sangi AR. Sangi
Huaiyin Institute of Technology Huaiyin Institute of Technology
T. Aanstoot T. Aanstoot
Modio AB Modio AB
S. Chakrabarti S. Chakrabarti
October 30, 2017 March 5, 2018
IPv6 over Constrained Node Networks (6lo) Applicability & Use cases IPv6 over Constrained Node Networks (6lo) Applicability & Use cases
draft-ietf-6lo-use-cases-03 draft-ietf-6lo-use-cases-04
Abstract Abstract
This document describes the applicability of IPv6 over constrained This document describes the applicability of IPv6 over constrained
node networks (6lo) and provides practical deployment examples. In node networks (6lo) and provides practical deployment examples. In
addition to IEEE 802.15.4, various link layer technologies such as addition to IEEE 802.15.4, various link layer technologies such as
ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, PLC (IEEE 1901.2), ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, PLC (IEEE 1901.2),
and IEEE 802.15.4e (6tisch) are used as examples. The document and IEEE 802.15.4e (6tisch) are used as examples. The document
targets an audience who like to understand and evaluate running end- targets an audience who like to understand and evaluate running end-
to-end IPv6 over the constrained link layer networks connecting to-end IPv6 over the constrained node networks connecting devices to
devices to each other or to each cloud. each other or to other devices on the Internet (e.g. cloud
infrastructure).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. 6lo Link layer technologies and possible candidates . . . . . 4 3. 6lo Link layer technologies and possible candidates . . . . . 4
3.1. ITU-T G.9959 (specified) . . . . . . . . . . . . . . . . 4 3.1. ITU-T G.9959 (specified) . . . . . . . . . . . . . . . . 4
3.2. Bluetooth LE (specified) . . . . . . . . . . . . . . . . 4 3.2. Bluetooth LE (specified) . . . . . . . . . . . . . . . . 4
3.3. DECT-ULE (specified) . . . . . . . . . . . . . . . . . . 5 3.3. DECT-ULE (specified) . . . . . . . . . . . . . . . . . . 5
3.4. MS/TP (specified) . . . . . . . . . . . . . . . . . . . . 5 3.4. MS/TP (specified) . . . . . . . . . . . . . . . . . . . . 5
3.5. NFC (specified) . . . . . . . . . . . . . . . . . . . . . 6 3.5. NFC (specified) . . . . . . . . . . . . . . . . . . . . . 6
3.6. PLC (specified) . . . . . . . . . . . . . . . . . . . . . 6 3.6. PLC (specified) . . . . . . . . . . . . . . . . . . . . . 7
3.7. IEEE 802.15.4e (specified) . . . . . . . . . . . . . . . 7 3.7. IEEE 802.15.4e (specified) . . . . . . . . . . . . . . . 7
3.8. LTE MTC (example of a potential candidate) . . . . . . . 8 3.8. LTE MTC (example of a potential candidate) . . . . . . . 8
3.9. Comparison between 6lo Link layer technologies . . . . . 8 3.9. Comparison between 6lo Link layer technologies . . . . . 9
4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 9 4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 10
4.1. jupitermesh in Smart Grid using 6lo in network layer . . 9 4.1. jupitermesh in Smart Grid using 6lo in network layer . . 10
4.2. Wi-SUN usage of 6lo stacks . . . . . . . . . . . . . . . 11 4.2. Wi-SUN usage of 6lo stacks . . . . . . . . . . . . . . . 12
5. Design Space and Guidelines for 6lo Deployment . . . . . . . 12 4.3. G3-PLC usage of 6lo in network layer . . . . . . . . . . 13
5.1. Design Space Dimensions for 6lo Deployment . . . . . . . 12 4.4. Netricity usage of 6lo in network layer . . . . . . . . . 14
5.2. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) . . . . 14 5. Design Space and Guidelines for 6lo Deployment . . . . . . . 15
6. 6lo Use Case Examples . . . . . . . . . . . . . . . . . . . . 16 5.1. Design Space Dimensions for 6lo Deployment . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5.2. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. 6lo Use Case Examples . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Other 6lo Use Case Examples . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
A.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 22
A.2. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 22 Appendix A. Other 6lo Use Case Examples . . . . . . . . . . . . 24
A.3. Use case of MS/TP: Management of District Heating . . . . 22 A.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 24
A.4. Use case of NFC: Alternative Secure Transfer . . . . . . 23 A.2. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 25
A.5. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 24 A.3. Use case of MS/TP: Building Automation Networks . . . . . 26
A.6. Use case of IEEE 802.15.4e: Industrial Automation . . . . 25 A.4. Use case of NFC: Alternative Secure Transfer . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 A.5. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 27
A.6. Use case of IEEE 802.15.4e: Industrial Automation . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Running IPv6 on constrained node networks has different features from Running IPv6 on constrained node networks has different features from
general node networks due to the characteristics of constrained node general node networks due to the characteristics of constrained node
networks such as small packet size, short link-layer address, low networks such as small packet size, short link-layer address, low
bandwidth, network topology, low power, low cost, and large number of bandwidth, network topology, low power, low cost, and large number of
devices [RFC4919][RFC7228]. For example, some IEEE 802.15.4 link devices [RFC4919][RFC7228]. For example, some IEEE 802.15.4 link
layers have a frame size of 127 octets and IPv6 requires the layer layers have a frame size of 127 octets and IPv6 requires the layer
below to support an MTU of 1280 bytes, therefore an appropriate below to support an MTU of 1280 bytes, therefore an appropriate
fragmentation and reassembly adaptation layer must be provided at the fragmentation and reassembly adaptation layer must be provided at the
layer below IPv6. Also, the limited size of IEEE 802.15.4 frame and layer below IPv6. Also, the limited size of IEEE 802.15.4 frame and
low energy consumption requirements make the need for header low energy consumption requirements make the need for header
compression. The IETF 6LoPWAN (IPv6 over Low powerWPAN) working compression. The IETF 6LoPWAN (IPv6 over Low powerWPAN) working
group published an adaptation layer for sending IPv6 packets over group published an adaptation layer for sending IPv6 packets over
IEEE 802.15.4 [RFC4944], a compression format for IPv6 datagrams over IEEE 802.15.4 [RFC4944], which includes a compression format for IPv6
IEEE 802.15.4-based networks [RFC6282], and Neighbor Discovery datagrams over IEEE 802.15.4-based networks [RFC6282], and Neighbor
Optimization for 6LoPWAN [RFC6775]. Discovery Optimization for 6LoPWAN [RFC6775].
As IoT (Internet of Things) services become more popular, IPv6 over As IoT (Internet of Things) services become more popular, IPv6 over
various link layer technologies such as Bluetooth Low Energy various link layer technologies such as Bluetooth Low Energy
(Bluetooth LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless (Bluetooth LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless
Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token
Passing (MS/TP), Near Field Communication (NFC), Power Line Passing (MS/TP), Near Field Communication (NFC), Power Line
Communication (PLC), and IEEE 802.15.4e (TSCH), have been defined at Communication (PLC), and IEEE 802.15.4e (TSCH), have been defined at
[IETF_6lo] working group. IPv6 stacks for constrained node networks [IETF_6lo] working group. IPv6 stacks for constrained node networks
use a variation of the 6LoWPAN stack applied to each particular link use a variation of the 6LoWPAN stack applied to each particular link
layer technology. layer technology.
In the 6LoPWAN working group, the [RFC6568], "Design and Application In the 6LoPWAN working group, the [RFC6568], "Design and Application
Spaces for 6LoWPANs" was published and it describes potential Spaces for 6LoWPANs" was published and it describes potential
application scenarios and use cases for low-power wireless personal application scenarios and use cases for low-power wireless personal
area networks. Hence, this 6lo applicability document aims to area networks. Hence, this 6lo applicability document aims to
provide guidance to an audience who is new to IPv6-over-lowpower provide guidance to an audience who are new to IPv6-over-low-power
networks concept and wants to assess if variance of 6LoWPAN stack networks concept and want to assess if variance of 6LoWPAN stack
[6lo] can be applied to the constrained L2 network of their interest. [6lo] can be applied to the constrained layer two (L2) network of
This 6lo applicability document puts together various design space their interest. This 6lo applicability document puts together
dimensions such as deployment, network size, power source, various design space dimensions such as deployment, network size,
connectivity, multi-hop communication, traffic pattern, security power source, connectivity, multi-hop communication, traffic pattern,
level, mobility, and QoS requirements etc. And it described a few security level, mobility, and QoS requirements etc. In addition, it
set of 6LoPWAN application scenarios and practical deployment as describes a few set of 6LoPWAN application scenarios and practical
examples. deployment as examples.
This document provides the applicability and use cases of 6lo, This document provides the applicability and use cases of 6lo,
considering the following aspects: considering the following aspects:
o 6lo applicability and use cases MAY be uniquely different from o 6lo applicability and use cases MAY be uniquely different from
those of 6LoWPAN defined for IEEE 802.15.4. those of 6LoWPAN defined for IEEE 802.15.4.
o It SHOULD cover various IoT related wire/wireless link layer o It SHOULD cover various IoT related wire/wireless link layer
technologies providing practical information of such technologies. technologies providing practical information of such technologies.
skipping to change at page 4, line 26 skipping to change at page 4, line 29
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. 6lo Link layer technologies and possible candidates 3. 6lo Link layer technologies and possible candidates
3.1. ITU-T G.9959 (specified) 3.1. ITU-T G.9959 (specified)
The ITU-T G.9959 recommendation [G.9959] targets low-power Personal The ITU-T G.9959 Recommendation [G.9959] targets low-power Personal
Area Networks (PANs). G.9959 defines how a unique 32-bit HomeID Area Networks (PANs), and defines physical layer and link layer
functionality. Physical layers of 9.6 kbit/s, 40 kbit/s and 100
kbit/s are supported. G.9959 defines how a unique 32-bit HomeID
network identifier is assigned by a network controller and how an network identifier is assigned by a network controller and how an
8-bit NodeID host identifier is allocated to each node. NodeIDs are 8-bit NodeID host identifier is allocated to each node. NodeIDs are
unique within the network identified by the HomeID. The G.9959 unique within the network identified by the HomeID. The G.9959
HomeID represents an IPv6 subnet that is identified by one or more HomeID represents an IPv6 subnet that is identified by one or more
IPv6 prefixes [RFC7428]. The ITU-T G.9959 can be used for smart home IPv6 prefixes [RFC7428]. The ITU-T G.9959 can be used for smart home
applications. applications.
3.2. Bluetooth LE (specified) 3.2. Bluetooth LE (specified)
Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth
4.1, and developed even further in successive versions. Bluetooth 4.1, and developed even further in successive versions. Bluetooth
SIG has also published Internet Protocol Support Profile (IPSP). The SIG has also published Internet Protocol Support Profile (IPSP). The
IPSP enables discovery of IP-enabled devices and establishment of IPSP enables discovery of IP-enabled devices and establishment of
link-layer connection for transporting IPv6 packets. IPv6 over link-layer connection for transporting IPv6 packets. IPv6 over
Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or
newer. newer.
Devices such as mobile phones, notebooks, tablets and other handheld Many Devices such as mobile phones, notebooks, tablets and other
computing devices which will include Bluetooth 4.1 chipsets will handheld computing devices which support Bluetooth 4.0 or subsequent
probably also have the low-energy variant of Bluetooth. Bluetooth LE chipsets also support the low-energy variant of Bluetooth. Bluetooth
will also be included in many different types of accessories that LE is also being included in many different types of accessories that
collaborate with mobile devices such as phones, tablets and notebook collaborate with mobile devices such as phones, tablets and notebook
computers. An example of a use case for a Bluetooth LE accessory is computers. An example of a use case for a Bluetooth LE accessory is
a heart rate monitor that sends data via the mobile phone to a server a heart rate monitor that sends data via the mobile phone to a server
on the Internet [RFC7668]. A typical usage of Bluetooth LE is on the Internet [RFC7668]. A typical usage of Bluetooth LE is
smartphone-based interaction with constrained devices. smartphone-based interaction with constrained devices. Bluetooth LE
was originally designed to enable star topology networks. However,
recent Bluetooth versions support the formation of extended
topologies, and IPv6 support for mesh networks of Bluetooth LE
devices is being developed [I-D.ietf-6lo-blemesh]
3.3. DECT-ULE (specified) 3.3. DECT-ULE (specified)
DECT ULE is a low power air interface technology that is designed to DECT ULE is a low power air interface technology that is designed to
support both circuit switched services, such as voice communication, support both circuit switched services, such as voice communication,
and packet mode data services at modest data rate. and packet mode data services at modest data rate.
The DECT ULE protocol stack consists of the PHY layer operating at The DECT ULE protocol stack consists of the PHY layer operating at
frequencies in the 1880 - 1920 MHz frequency band depending on the frequencies in the 1880 - 1920 MHz frequency band depending on the
region and uses a symbol rate of 1.152 Mbps. Radio bearers are region and uses a symbol rate of 1.152 Mbps. Radio bearers are
skipping to change at page 5, line 41 skipping to change at page 5, line 49
layer ensures packet integrity and preserves packet order, but layer ensures packet integrity and preserves packet order, but
delivery is based on best effort. delivery is based on best effort.
The current DECT ULE MAC layer standard supports low bandwidth data The current DECT ULE MAC layer standard supports low bandwidth data
broadcast. However the usage of this broadcast service has not yet broadcast. However the usage of this broadcast service has not yet
been standardized for higher layers [RFC8105]. DECT-ULE can be used been standardized for higher layers [RFC8105]. DECT-ULE can be used
for smart metering in a home. for smart metering in a home.
3.4. MS/TP (specified) 3.4. MS/TP (specified)
MS/TP is a contention-free access method for the RS-485 physical Master-Slave/Token-Passing (MS/TP) is a Medium Access Control (MAC)
layer, which is used extensively in building automation networks. protocol for the RS-485 [TIA-485-A] physical layer and is used
primarily in building automation networks.
An MS/TP device is typically based on a low-cost microcontroller with An MS/TP device is typically based on a low-cost microcontroller with
limited processing power and memory. Together with low data rates limited processing power and memory. These constraints, together
and a small address space, these constraints are similar to those with low data rates and a small MAC address space, are similar to
faced in 6LoWPAN networks and suggest some elements of that solution those faced in 6LoWPAN networks. MS/TP differs significantly from
might be leveraged. MS/TP differs significantly from 6LoWPAN in at 6LoWPAN in at least three respects: a) MS/TP devices are typically
least three aspects: a) MS/TP devices typically have a continuous mains powered, b) all MS/TP devices on a segment can communicate
source of power, b) all MS/TP devices on a segment can communicate
directly so there are no hidden node or mesh routing issues, and c) directly so there are no hidden node or mesh routing issues, and c)
recent changes to MS/TP provide support for large payloads, the latest MS/TP specification provides support for large payloads,
eliminating the need for link-layer fragmentation and reassembly. eliminating the need for fragmentation and reassembly below IPv6.
MS/TP is designed to enable multidrop networks over shielded twisted MS/TP is designed to enable multidrop networks over shielded twisted
pair wiring, although not according to standards, in lower speeds, pair wiring. It can support network segments up to 1000 meters in
normally 9600 bit/s, re-purposed telecom wiring is widely in use, length at a data rate of 115.2 kbit/s or segments up to 1200 meters
keeping deployment cost down. It can support a data rate of 115,200 in length at lower bit rates. An MS/TP interface requires only a
baud on segments up to 1000 meters in length, or segments up to 1200 UART, an RS-485 [TIA-485-A] transceiver with a driver that can be
meters in length at lower baud rates. An MS/TP link requires only a disabled, and a 5 ms resolution timer. The MS/TP MAC is typically
UART, an RS-485 transceiver with a driver that can be disabled, and a implemented in software.
5ms resolution timer. These features make MS/TP a cost-effective and
very reliable field bus for the most numerous and least expensive Because of its superior "range" (~1 km) compared to many low power
devices in a building automation network [RFC8163]. MS/TP can be wireless data links, MS/TP may be suitable to connect remote devices
used for the management of district heating. (such as district heating controllers) to the nearest building
control infrastructure over a single link [RFC8163]. MS/TP can be
used for building automation networks.
3.5. NFC (specified) 3.5. NFC (specified)
NFC technology enables simple and safe two-way interactions between NFC technology enables simple and safe two-way interactions between
electronic devices, allowing consumers to perform contactless electronic devices, allowing consumers to perform contactless
transactions, access digital content, and connect electronic devices transactions, access digital content, and connect electronic devices
with a single touch. NFC complements many popular consumer level with a single touch. NFC complements many popular consumer level
wireless technologies, by utilizing the key elements in existing wireless technologies, by utilizing the key elements in existing
standards for contactless card technology (ISO/IEC 14443 A&B and standards for contactless card technology (ISO/IEC 14443 A&B and
JIS-X 6319-4). NFC can be compatible with existing contactless card JIS-X 6319-4). NFC can be compatible with existing contactless card
skipping to change at page 6, line 46 skipping to change at page 7, line 7
simple touch. simple touch.
NFC's bidirectional communication ability is ideal for establishing NFC's bidirectional communication ability is ideal for establishing
connections with other technologies by the simplicity of touch. In connections with other technologies by the simplicity of touch. In
addition to the easy connection and quick transactions, simple data addition to the easy connection and quick transactions, simple data
sharing is also available [I-D.ietf-6lo-nfc]. NFC can be used for sharing is also available [I-D.ietf-6lo-nfc]. NFC can be used for
secure transfer in healthcare services. secure transfer in healthcare services.
3.6. PLC (specified) 3.6. PLC (specified)
Unlike other dedicated communication infrastructure, the required PLC is a data transmission technique that utilizes power conductors
medium (power conductor) is widely available indoors and outdoors. as medium. Unlike other dedicated communication infrastructure,
power conductors are widely available indoors and outdoors.
Moreover, wired technologies are more susceptible to cause Moreover, wired technologies are more susceptible to cause
interference but are more reliable than their wireless counterparts. interference but are more reliable than their wireless counterparts.
PLC is a data transmission technique that utilizes power conductors PLC is a data transmission technique that utilizes power conductors
as medium. as medium.
The below table shows some available open standards defining PLC. The below table shows some available open standards defining PLC.
+-------------+-----------------+------------+-----------+----------+ +-------------+-----------------+------------+-----------+----------+
| PLC Systems | Frequency Range | Type | Data Rate | Distance | | PLC Systems | Frequency Range | Type | Data Rate | Distance |
+-------------+-----------------+------------+-----------+----------+ +-------------+-----------------+------------+-----------+----------+
| IEEE1901 | <100MHz | Broadband | 200Mbps | 1000m | | IEEE1901 | <100MHz | Broadband | 200Mbps | 1000m |
| | | | | | | | | | | |
| IEEE1901.1 | <15MHz | PLC-IoT | 10Mbps | 2000m | | IEEE1901.1 | <15MHz | PLC-IoT | 10Mbps | 2000m |
| | | | | | | | | | | |
| IEEE1901.2 | <500kHz | Narrowband | 200Kbps | 3000m | | IEEE1901.2 | <500kHz | Narrowband | 200Kbps | 3000m |
+-------------+-----------------+------------+-----------+----------+ +-------------+-----------------+------------+-----------+----------+
Table 1: Some Available Open Standards in PLC Table 1: Some Available Open Standards in PLC
[IEEE1901] defines broadband variant of PLC but is effective within [IEEE1901] defines a broadband variant of PLC but is effective within
short range. This standard addresses the requirements of short range. This standard addresses the requirements of
applications with high data rate such as: Internet, HDTV, Audio, applications with high data rate such as: Internet, HDTV, Audio,
Gaming etc. Broadband operates on OFDM (Orthogonal Frequency Gaming etc. Broadband operates on OFDM (Orthogonal Frequency
Division Multiplexing) modulation. Division Multiplexing) modulation.
[IEEE1901.2] defines narrowband variant of PLC with less data rate [IEEE1901.2] defines a narrowband variant of PLC with less data rate
but significantly higher transmission range that could be used in an but significantly higher transmission range that could be used in an
indoor or even an outdoor environment. It is applicable to typical indoor or even an outdoor environment. It is applicable to typical
IoT applications such as: Building Automation, Renewable Energy, IoT applications such as: Building Automation, Renewable Energy,
Advanced Metering, Street Lighting, Electric Vehicle, Smart Grid etc. Advanced Metering, Street Lighting, Electric Vehicle, Smart Grid etc.
Moreover, IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer Moreover, IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer
and fully endorses the security scheme defined in 802.15.4. and fully endorses the security scheme defined in 802.15.4 [RFC8036].
[RFC8036]. A typical use case of PLC is smart grid. A typical use case of PLC is smart grid.
3.7. IEEE 802.15.4e (specified) 3.7. IEEE 802.15.4e (specified)
The Time Slotted Channel Hopping (TSCH) mode was introduced in the The Time Slotted Channel Hopping (TSCH) mode was introduced in the
IEEE 802.15.4-2015 standard. In a TSCH network, all nodes are IEEE 802.15.4-2015 standard. In a TSCH network, all nodes are
synchronized. Time is sliced up into timeslots. The duration of a synchronized. Time is sliced up into timeslots. The duration of a
timeslot, typically 10ms, is large enough for a node to send a full- timeslot, typically 10ms, is large enough for a node to send a full-
sized frame to its neighbor, and for that neighbor to send back an sized frame to its neighbor, and for that neighbor to send back an
acknowledgment to indicate successful reception. Timeslots are acknowledgment to indicate successful reception. Timeslots are
grouped into one of more slotframes, which repeat over time. grouped into one of more slotframes, which repeat over time.
skipping to change at page 8, line 28 skipping to change at page 8, line 38
offer over a decade of battery lifetime. offer over a decade of battery lifetime.
- 6TiSCH at IETF defines communications of TSCH network and it - 6TiSCH at IETF defines communications of TSCH network and it
uses 6LoWPAN stack [RFC7554]. uses 6LoWPAN stack [RFC7554].
IEEE 802.15.4e can be used for industrial automation. IEEE 802.15.4e can be used for industrial automation.
3.8. LTE MTC (example of a potential candidate) 3.8. LTE MTC (example of a potential candidate)
LTE category defines the overall performance and capabilities of the LTE category defines the overall performance and capabilities of the
UE(User Equipment). For example, the maximum down rate of category 1 UE (User Equipment). For example, the maximum down rate of category
UE and category 2 UE are 10.3 Mbit/s and 51.0 Mbit/s respectively. 1 UE and category 2 UE are 10.3 Mbit/s and 51.0 Mbit/s respectively.
There are many categories in LTE standard. 3GPP standards defined the There are many categories in LTE standards. 3GPP standards defined
category 0 to be used for low rate IoT service in release 12. Since the category 0 to be used for low rate IoT service in release 12.
category 1 and category 0 could be used for low rate IoT service, Since category 1 and category 0 could be used for low rate IoT
these categories are called LTE MTC (Machine Type Communication) service, these categories are called LTE MTC (Machine Type
[LTE_MTC]. Communication) [LTE_MTC]. And 3GPP standards defined the MTC
Enhancements in release 13.
LTE MTC offer advantages in comparison to above category 2 and is LTE MTC offer advantages in comparison to above category 2 and is
appropriate to be used for low rate IoT services such as low power appropriate to be used for low rate IoT services such as low power
and low cost. LTE MTC can be used for a gateway of a wireless and low cost.
bachhaul network.
LTE MTC can be used for tracking services, such as asset tracker,
bicycle/cat tracker and etc with national wide. LTE MTC can be also
used for monitoring & control service, such as car mobility record
and weather observation that require much more traffic than other IoT
services. Since the traffic collected by other IoT devices such as
LoRa, Z-wave and BLE is small, LTE MTC can be used as a bachhaul of
other IoT networks.
3.9. Comparison between 6lo Link layer technologies 3.9. Comparison between 6lo Link layer technologies
In above clauses, various 6lo Link layer technologies and a possible In above clauses, various 6lo Link layer technologies and a possible
candidate are described. The following table shows that dominant candidate are described. The following table shows that dominant
paramters of each use case corresponding to the 6lo link layer paramters of each use case corresponding to the 6lo link layer
technology. technology.
+-----------+--------+--------+--------+--------+--------+--------+--------+ +-----------+--------+--------+--------+--------+--------+--------+--------+
| | Z-Wave | BLE |DECT-ULE| MS/TP | NFC | PLC | TSCH | | | Z-Wave | BLE |DECT-ULE| MS/TP | NFC | PLC | TSCH |
+-----------+--------+--------+--------+--------+--------+--------+--------+ +-----------+--------+--------+--------+--------+--------+--------+--------+
| | Home |Interact| | | Health-| |Industr-| | | Home |Interact| |Building| Health-| |Industr-|
| Usage | Auto- |w/ Smart| Meter |District| care | Smart |ial Aut-| | Usage | Auto- |w/ Smart| Meter | Auto- | care | Smart |ial Aut-|
| | mation | Phone | Reading| Heating| Service| Grid | mation | | | mation | Phone | Reading| mation | Service| Grid | mation |
+-----------+--------+--------+--------+--------+--------+--------+--------+ +-----------+--------+--------+--------+--------+--------+--------+--------+
| Topology | L2-mesh| Star | Star | Bus | P2P | Star | | | Topology | L2-mesh| Star | Star | MS/TP | P2P | Star | |
| & | or | | | | | Tree | Mesh | | & | or | & | | | | Tree | Mesh |
| Subnet | L3-mesh| No mesh| No mesh| MS/TP | L2-mesh| Mesh | | | Subnet | L3-mesh| Mesh | No mesh| No mesh| L2-mesh| Mesh | |
+-----------+--------+--------+--------+--------+--------+--------+--------+ +-----------+--------+--------+--------+--------+--------+--------+--------+
| | | | | | | | | | | | | | | | | |
| Mobility | No | Low | No | No |Moderate| No | No | | Mobility | No | Low | No | No |Moderate| No | No |
| Reqmt | | | | | | | | | Reqmt | | | | | | | |
+-----------+--------+--------+--------+--------+--------+--------+--------+ +-----------+--------+--------+--------+--------+--------+--------+--------+
| | High + | | High + | High + | | High + | High + | | | High + | | High + | High + | | High + | High + |
| Security | Privacy| Parti- | Privacy| Authen.| High |Encrypt.| Privacy| | Security | Privacy| Parti- | Privacy| Authen.| High |Encrypt.| Privacy|
| Reqmt |required| ally |required|required| |required|required| | Reqmt |required| ally |required|required| |required|required|
+-----------+--------+--------+--------+--------+--------+--------+--------+ +-----------+--------+--------+--------+--------+--------+--------+--------+
| | | | | | | | | | | | | | | | | |
| Buffering | Low | Low | Low | Low | Low | Low | Low | | Buffering | Low | Low | Low | Low | Low | Low | Low |
| Reqmpt | | | | | | | | | Reqmt | | | | | | | |
+-----------+--------+--------+--------+--------+--------+--------+--------+ +-----------+--------+--------+--------+--------+--------+--------+--------+
| Latency, | | | | | | | | | Latency, | | | | | | | |
| QoS | High | Low | Low | High | High | Low | High | | QoS | High | Low | Low | High | High | Low | High |
| Reqmt | | | | | | | | | Reqmt | | | | | | | |
+-----------+--------+--------+--------+--------+--------+--------+--------+ +-----------+--------+--------+--------+--------+--------+--------+--------+
| | | | | | | | | | | | | | | | | |
| Data |Infrequ-|Infrequ-|Infrequ-|Frequent| Small |Infrequ-|Infrequ-| | Data |Infrequ-|Infrequ-|Infrequ-|Frequent| Small |Infrequ-|Infrequ-|
| Rate | ent | ent | ent | | | ent | ent | | Rate | ent | ent | ent | | | ent | ent |
+-----------+--------+--------+--------+--------+--------+--------+--------+ +-----------+--------+--------+--------+--------+--------+--------+--------+
| RFC # | | | | | draft- | draft- | | | RFC # | | | | | draft- | draft- | |
| or | RFC7428| RFC7668| RFC8105| RFC8163|ietf-6lo|hou-6lo-| RFC7554| | or | RFC7428| RFC7668| RFC8105| RFC8163|ietf-6lo|hou-6lo-| RFC7554|
| Draft | | | | | -nfc | plc | | | Draft | | | | | -nfc | plc | |
+-----------+--------+--------+--------+--------+--------+--------+--------+ +-----------+--------+--------+--------+--------+--------+--------+--------+
Table 2: Comparison between 6lo Link layer technologies Table 2: Comparison between 6lo Link layer technologies
4. 6lo Deployment Scenarios 4. 6lo Deployment Scenarios
4.1. jupitermesh in Smart Grid using 6lo in network layer 4.1. jupitermesh in Smart Grid using 6lo in network layer
jupiterMesh is a multi-hop wireless mesh network specification jupiterMesh is a multi-hop wireless mesh network specification
designed mainly for deployment in large geographical areas. Each designed mainly for deployment in large geographical areas. Each
subnet in jupiterMesh is able to cover an entire neighborhood with subnet in jupiterMesh is able to cover an entire neighborhood with
thousands of nodes consisting of IPv6-enabled routers and end-points thousands of nodes consisting of IPv6-enabled routers and end-points
(e.g., hosts). Automated network joining and load balancing allows a (e.g. hosts). Automated network joining and load balancing allows a
seamless deployment of a large number of subnets. seamless deployment of a large number of subnets.
The main application domains targeted by jupiterMesh are smart grid The main application domains targeted by jupiterMesh are smart grid
and smart cities. This includes, but is not limited to the following and smart cities. This includes, but is not limited to the following
applications: applications:
o Automated meter reading o Automated meter reading
o Distribution Automation (DA) o Distribution Automation (DA)
skipping to change at page 12, line 36 skipping to change at page 13, line 36
o Very low power modes in development permitting long term battery o Very low power modes in development permitting long term battery
operation of network nodes operation of network nodes
In the Wi-SUN FAN specification, adaptation layer based on 6lo and In the Wi-SUN FAN specification, adaptation layer based on 6lo and
IPv6 network layer are described. So, IPv6 protocol suite including IPv6 network layer are described. So, IPv6 protocol suite including
TCP/UDP, 6lo Adaptation, Header Compression, DHCPv6 for IP address TCP/UDP, 6lo Adaptation, Header Compression, DHCPv6 for IP address
management, Routing using RPL, ICMPv6, and Unicast/Multicast management, Routing using RPL, ICMPv6, and Unicast/Multicast
forwarding is utilized. forwarding is utilized.
4.3. G3-PLC usage of 6lo in network layer
G3-PLC [G3-PLC] is a narrow-band PLC technology that is based on
ITU-T G.9903 Recommendation [G.9903]. G3-PLC supports multi-hop mesh
network, 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 NB-PLC technologies.
G3-PLC has got massive deployments over several countries, e.g.
Japan and France.
The main application domains targeted by G3-PLC are smart grid and
smart cities. This includes, but is not limited to the following
applications:
o Smart Metering
o Vehicle-to-Grid Communication
o Demand Response (DR)
o Distribution Automation
o Home/Building Energy Management Systems
o Smart Street Lighting
o Advanced Metering Infrastructure (AMI) backbone network
o Wind/Solar Farm Monitoring
In the G3-PLC specification, the 6lo adaptation layer utilizes the
6LoWPAN functions (e.g. header compression, fragmentation and
reassembly) so as to enable IPv6 packet transmission. LOADng, which
is a lightweight variant of AODV, is applied as the mesh-under
routing protocol in G3-PLC networks. Address assignment and network
configuration are based on the bootstrapping protocol specified in
ITU-T G.9903. The network layer consists of IPv6 and ICMPv6 while
the transport protocol UDP is used for data transmission.
4.4. Netricity usage of 6lo in network layer
The Netricity program in HomePlug Powerline Alliance [NETRICITY]
promotes the adoption of products built on the IEEE 1901.2 Low-
Frequency Narrow-Band PLC standard, which provides for urban and long
distance communications and propagation through transformers of the
distribution network using frequencies below 500 kHz. The technology
also addresses requirements that assure communication privacy and
secure networks.
The main application domains targeted by Netricity are smart grid and
smart cities. This includes, but is not limited to the following
applications:
o Utility grid modernization
o Distribution automation
o Meter-to-Grid connectivity
o Micro-grids
o Grid sensor communications
o Load control
o Demand response
o Net metering
o Street Lighting control
o Photovoltaic panel monitoring
Netricity system architecture is based on the PHY and MAC layers of
IEEE 1901.2 PLC standard. Regarding the 6lo adaptation layer and
IPv6 network layer, Netricity utilizes IPv6 protocol suite including
6lo/6LoWPAN header compression, DHCPv6 for IP address management, RPL
routing protocol, ICMPv6, and unicast/multicast forwarding. Note
that the layer 3 routing in Netricity uses RPL in non-storing mode
with the MRHOF objective function based on the own defined Estimated
Transmission Time (ETT) metric.
5. Design Space and Guidelines for 6lo Deployment 5. Design Space and Guidelines for 6lo Deployment
5.1. Design Space Dimensions for 6lo Deployment 5.1. Design Space Dimensions for 6lo Deployment
The [RFC6568] lists the dimensions used to describe the design space The [RFC6568] lists the dimensions used to describe the design space
of wireless sensor networks in the context of the 6LoWPAN working of wireless sensor networks in the context of the 6LoWPAN working
group. The design space is already limited by the unique group. The design space is already limited by the unique
characteristics of a LoWPAN (e.g., low power, short range, low bit characteristics of a LoWPAN (e.g. low power, short range, low bit
rate). In [RFC6568], design space dimensions are described; rate). In [RFC6568], the following design space dimensions are
Deployment, Network size, Power source, Connectivity, Multi-hop described: Deployment, Network size, Power source, Connectivity,
communication, Traffic pattern, Mobility, Quality of Service (QoS). Multi-hop communication, Traffic pattern, Mobility, Quality of
However, in this document, the following design space dimensions are Service (QoS). However, in this document, the following design space
considered: dimensions are considered:
o Deployment/Bootstrapping: 6lo nodes can be connected randomly, or o Deployment/Bootstrapping: 6lo nodes can be connected randomly, or
in an organized manner. The bootstrapping has different in an organized manner. The bootstrapping has different
characteristics for each link layer technology. characteristics for each link layer technology.
o Topology: Topology of 6lo networks may inherently follow the o Topology: Topology of 6lo networks may inherently follow the
characteristics of each link layer technology. Point-to-point, characteristics of each link layer technology. Point-to-point,
star, tree or mesh topologies can be configured, depending on the star, tree or mesh topologies can be configured, depending on the
link layer technology considered. link layer technology considered.
o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the
characteristics of each link layer technology. Some link layer characteristics of each link layer technology. Some link layer
technologies may support L2-mesh and some may not support. technologies may support L2-mesh and some may not support.
o Multi-link subnet, single subnet: The selection of multi-link o Multi-link subnet, single subnet: The selection of multi-link
subnet and single subnet depends on connectivity and the number of subnet and single subnet depends on connectivity and the number of
6lo nodes. 6lo nodes.
o Data rate: Originally, the link layer technologies of 6lo have low o Data rate: Typically, the link layer technologies of 6lo have low
rate of data transmission. But, by adjusting the MTU, it can rate of data transmission. But, by adjusting the MTU, it can
deliver higher data rate. deliver higher upper layer data rate.
o Buffering requirements: Some 6lo use case may require more data o Buffering requirements: Some 6lo use case may require more data
rate than the link layer technology support. In this case, a rate than the link layer technology support. In this case, a
buffering mechanism to manage the data is required. buffering mechanism to manage the data is required.
o Security and Privacy Requirements: Some 6lo use case can involve o Security and Privacy Requirements: Some 6lo use case can involve
transferring some important and personal data between 6lo nodes. transferring some important and personal data between 6lo nodes.
In this case, high-level security support is required. In this case, high-level security support is required.
o Mobility across 6lo networks and subnets: The movement of 6lo o Mobility across 6lo networks and subnets: The movement of 6lo
nodes is dependent on the 6lo use case. If the 6lo nodes can move nodes depends on the 6lo use case. If the 6lo nodes can move or
or moved around, it requires a mobility management mechanism. moved around, a mobility management mechanism is required.
o Time synchronization requirements: The requirement of time o Time synchronization requirements: The requirement of time
synchronization of the upper layer service is dependent on the 6lo synchronization of the upper layer service is dependent on the 6lo
use case. For some 6lo use case related to health service, the use case. For some 6lo use case related to health service, the
measured data must be recorded with exact time and must be measured data must be recorded with exact time and must be
transferred with time synchronization. transferred with time synchronization.
o Reliability and QoS: Some 6lo use case requires high reliability, o Reliability and QoS: Some 6lo use case requires high reliability,
for example real-time service or health-related services. for example real-time service or health-related services.
skipping to change at page 14, line 21 skipping to change at page 16, line 51
layer technology defines a particular power use strategy which may layer technology defines a particular power use strategy which may
be tuned [I-D.ietf-lwig-energy-efficient]. Readers are expected be tuned [I-D.ietf-lwig-energy-efficient]. Readers are expected
to be familiar with [RFC7228] terminology. to be familiar with [RFC7228] terminology.
o Update firmware requirements: Most 6lo use cases will need a o Update firmware requirements: Most 6lo use cases will need a
mechanism for updating firmware. In these cases support for over mechanism for updating firmware. In these cases support for over
the air updates are required, probably in a broadcast mode when the air updates are required, probably in a broadcast mode when
bandwith is low and the number of identical devices is high. bandwith is low and the number of identical devices is high.
o Wired vs. Wireless: Plenty of 6lo link layer technologies are o Wired vs. Wireless: Plenty of 6lo link layer technologies are
wireless except MS/TP and PLC. The selection of wired or wireless wireless, except MS/TP and PLC. The selection of wired or
link layer technology is mainly dependent on the requirement of wireless link layer technology is mainly dependent on the
6lo use cases and the characteristics of wired/wireless requirement of 6lo use cases and the characteristics of wired/
technologies. For example, some 6lo use cases may require easy wireless technologies. For example, some 6lo use cases may
and quick deployment and some 6lo use cases may require continuous require easy and quick deployment, whereas others may need a
source of power. continuous source of power.
5.2. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) 5.2. Guidelines for adopting IPv6 stack (6lo/6LoWPAN)
The following guideline targets candidates for new constrained L2 The following guideline targets new candidate constrained L2
technologies that consider running modified 6LoWPAN stack. The technologies that may be considered for running modified 6LoWPAN
modification of 6LoWPAN stack should be based on the following: stack on top. The modification of 6LoWPAN stack should be based on
the following:
o Addressing Model: Addressing model determines whether the device o Addressing Model: Addressing model determines whether the device
is capable of forming IPv6 Link-local and global addresses and is capable of forming IPv6 Link-local and global addresses and
what is the best way to derive the IPv6 addresses for the what is the best way to derive the IPv6 addresses for the
constrained L2 devices. Whether the device is capable of forming constrained L2 devices. Whether the device is capable of forming
IPv6 Link-local and global addresses, L2-address-derived IPv6 IPv6 Link-local and global addresses, L2-address-derived IPv6
addresses are specified in [RFC4944], but there exist implications addresses are specified in [RFC4944], but there exist implications
for privacy. For global usage, a unique IPv6 address must be for privacy. For global usage, a unique IPv6 address must be
derived using an assigned prefix and a unique interface ID. derived using an assigned prefix and a unique interface ID.
[RFC8065] provides such guidelines. For MAC derived IPv6 address, [RFC8065] provides such guidelines. For MAC derived IPv6 address,
please refer to [RFC8163] for IPv6 address mapping examples. please refer to [RFC8163] for IPv6 address mapping examples.
Broadcast and multicast support are dependent on the L2 networks. Broadcast and multicast support are dependent on the L2 networks.
Most lowpower L2 implementations map multicast to broadcast Most low-power L2 implementations map multicast to broadcast
networks. So care must be taken in the design when to use networks. So care must be taken in the design when to use
broadcast and try to stick to unicast messaging whenever possible. broadcast and try to stick to unicast messaging whenever possible.
o MTU Considerations: The deployment SHOULD consider their need for o MTU Considerations: The deployment SHOULD consider their need for
maximum transmission unit of a packet (MTU) over the link layer maximum transmission unit (MTU) of a packet over the link layer
and should consider if fragmentation and reassembly of packets are and should consider if fragmentation and reassembly of packets are
needed at the 6LoWPAN layer. For example, if the link-layer needed at the 6LoWPAN layer. For example, if the link layer
supports fragmentation and reassembly of packets, then 6LoWPAN supports fragmentation and reassembly of packets, then 6LoWPAN
layer may skip supporting fragmentation/reassembly. In fact, for layer may skip supporting fragmentation/reassembly. In fact, for
most efficiency, choosing a low-power link-layer that can carry most efficiency, choosing a low-power link layer that can carry
unfragmented application packets would be optimum for packet unfragmented application packets would be optimum for packet
transmission if the deployment can afford it. Please refer to 6lo transmission if the deployment can afford it. Please refer to 6lo
RFCs [RFC7668], [RFC8163], [RFC8105] for example guidance. RFCs [RFC7668], [RFC8163], [RFC8105] for example guidance.
o Mesh or L3-Routing: 6LoWPAN specifications do provide mechanisms o Mesh or L3-Routing: 6LoWPAN specifications do provide mechanisms
to support for mesh routing at L2. [RFC6550] defines L3 routing to support for mesh routing at L2. [RFC6550] defines layer three
for low power lossy networks using directed graphs. 6LoWPAN is (L3) routing for low power lossy networks using directed graphs.
routing protocol agnostic and other L2 or L3 routing protocols can 6LoWPAN is routing protocol agnostic and other L2 or L3 routing
be run using a 6LoWPAN stack. protocols can be run using a 6LoWPAN stack.
o Address Assignment: 6LoWPAN requires that IPv6 Neighbor Discovery o Address Assignment: 6LoWPAN requires that IPv6 Neighbor Discovery
for low power networks [RFC6775] be used for autoconfiguration of for low power networks [RFC6775] be used for autoconfiguration of
stateless IPv6 address assignment. Considering the energy stateless IPv6 address assignment. Considering the energy
sensitive networks [RFC6775] makes optimization from classical sensitive networks [RFC6775] makes optimization from classical
IPv6 ND [RFC4861] protocol. It is the responsibility of the IPv6 ND [RFC4861] protocol. It is the responsibility of the
deployment to ensure unique global IPv6 addresses for the Internet deployment to ensure unique global IPv6 addresses for the Internet
connectivity. For local-only connectivity IPv6 ULA may be used. connectivity. For local-only connectivity IPv6 ULA may be used.
[RFC6775] specifies the 6LoWPAN border router(6LBR) which is [RFC6775] specifies the 6LoWPAN border router(6LBR) which is
responsible for prefix assignment to the 6lo/6LoWPAN network. 6LBR responsible for prefix assignment to the 6lo/6LoWPAN network. 6LBR
skipping to change at page 15, line 42 skipping to change at page 18, line 25
business reasons and may choose to offer a separate address business reasons and may choose to offer a separate address
assignment service. assignment service.
o Header Compression: IPv6 header compression [RFC6282] is a vital o Header Compression: IPv6 header compression [RFC6282] is a vital
part of IPv6 over low power communication. Examples of header part of IPv6 over low power communication. Examples of header
compression for different link-layers specifications are found in compression for different link-layers specifications are found in
[RFC7668], [RFC8163], [RFC8105]. A generic header compression [RFC7668], [RFC8163], [RFC8105]. A generic header compression
technique is specified in [RFC7400]. technique is specified in [RFC7400].
o Security and Encryption: Though 6LoWPAN basic specifications do o Security and Encryption: Though 6LoWPAN basic specifications do
not address security at network layer, the assumption is that L2 not address security at the network layer, the assumption is that
security must be present. In addition, application level security L2 security must be present. In addition, application level
is highly desirable. The working groups [ace] and [core] should security is highly desirable. The working groups [ace] and [core]
be consulted for application and transport level security. 6lo should be consulted for application and transport level security.
working group is working on address authentication [6lo-ap-nd] and 6lo working group is working on address authentication [6lo-ap-nd]
secure bootstrapping is also being discussed at IETF. However, and secure bootstrapping is also being discussed at IETF.
there may be different levels of security available in a However, there may be different levels of security available in a
deployment through other standards such as hardware level security deployment through other standards such as hardware level security
or certificates for initial booting process. Encryption is quite or certificates for initial booting process. Encryption is
important if the implementation can afford it. important if the implementation can afford it.
o Additional processing: [RFC8066] defines guidelines for ESC o Additional processing: [RFC8066] defines guidelines for ESC
dispatch octets use in the 6LoWPAN header. An implementation may dispatch octets use in the 6LoWPAN header. An implementation may
take advantage of ESC header to offer a deployment specific take advantage of ESC header to offer a deployment specific
processing of 6LoWPAN packets. processing of 6LoWPAN packets.
6. 6lo Use Case Examples 6. 6lo Use Case Examples
As IPv6 stacks for constrained node networks use a variation of the As IPv6 stacks for constrained node networks use a variation of the
skipping to change at page 16, line 48 skipping to change at page 19, line 31
the smartphone, which can forward the data to a cloud service on the the smartphone, which can forward the data to a cloud service on the
Internet. In addition, the smartwatch can receive notifications Internet. In addition, the smartwatch can receive notifications
(e.g. alarm signals) from the cloud service via the smartphone. On (e.g. alarm signals) from the cloud service via the smartphone. On
the other hand, the smartphone may locally generate messages for the the other hand, the smartphone may locally generate messages for the
smartwatch, such as e-mail reception or calendar notifications. smartwatch, such as e-mail reception or calendar notifications.
The functionality supported by the smartwatch may be complemented by The functionality supported by the smartwatch may be complemented by
other devices such as other on-body sensors, wireless headsets or other devices such as other on-body sensors, wireless headsets or
head-mounted displays. All such devices may connect to the head-mounted displays. All such devices may connect to the
smartphone creating a star topology network whereby the smartphone is smartphone creating a star topology network whereby the smartphone is
the central component. the central component. Support for extended network topologies (e.g.
mesh networks) is being developed as of the writing.
7. IANA Considerations 7. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
8. Security Considerations 8. Security Considerations
Security considerations are not directly applicable to this document. Security considerations are not directly applicable to this document.
The use cases will use the security requirements described in the The use cases will use the security requirements described in the
protocol specifications. protocol specifications.
9. Acknowledgements 9. Acknowledgements
Carles Gomez has been funded in part by the Spanish Government Carles Gomez has been funded in part by the Spanish Government
(Ministerio de Educacion, Cultura y Deporte) through the Jose through the Jose Castillejo CAS15/00336 grant, and through the
Castillejo grant CAS15/00336. His contribution to this work has been TEC2016-79988-P grant. His contribution to this work has been
carried out in part during his stay as a visiting scholar at the carried out in part during his stay as a visiting scholar at the
Computer Laboratory of the University of Cambridge. Computer Laboratory of the University of Cambridge.
Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault, Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault,
and Jianqiang HOU have provided valuable feedback for this draft. and Jianqiang HOU have provided valuable feedback for this draft.
Das Subir and Michel Veillette have provided valuable information of Das Subir and Michel Veillette have provided valuable information of
jupiterMesh and Paul Duffy has provided valuable information of Wi- jupiterMesh and Paul Duffy has provided valuable information of Wi-
SUN for this draft. SUN for this draft. Also, Jianqiang Hou has provided valuable
information of G3-PLC and Netricity for this draft. Kerry Lynn and
Dave Robin have provided valuable information of MS/TP and practical
use case of MS/TP for this draft.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 20, line 13 skipping to change at page 22, line 37
2003, <https://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[I-D.ietf-6lo-nfc] [I-D.ietf-6lo-nfc]
Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi,
"Transmission of IPv6 Packets over Near Field "Transmission of IPv6 Packets over Near Field
Communication", draft-ietf-6lo-nfc-07 (work in progress), Communication", draft-ietf-6lo-nfc-09 (work in progress),
June 2017. January 2018.
[I-D.ietf-lwig-energy-efficient] [I-D.ietf-lwig-energy-efficient]
Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy-
Efficient Features of Internet of Things Protocols", Efficient Features of Internet of Things Protocols",
draft-ietf-lwig-energy-efficient-08 (work in progress), draft-ietf-lwig-energy-efficient-08 (work in progress),
October 2017. October 2017.
[I-D.ietf-roll-aodv-rpl] [I-D.ietf-roll-aodv-rpl]
Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S. Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S.
Anand, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy Anand, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy
Networks (LLNs)", draft-ietf-roll-aodv-rpl-02 (work in Networks (LLNs)", draft-ietf-roll-aodv-rpl-02 (work in
progress), September 2017. progress), September 2017.
[I-D.ietf-6tisch-6top-sf0] [I-D.ietf-6tisch-6top-sfx]
Dujovne, D., Grieco, L., Palattella, M., and N. Accettura, Dujovne, D., Grieco, L., Palattella, M., and N. Accettura,
"6TiSCH 6top Scheduling Function Zero (SF0)", draft-ietf- "6TiSCH 6top Scheduling Function Zero / Experimental
6tisch-6top-sf0-05 (work in progress), July 2017. (SFX)", draft-ietf-6tisch-6top-sfx-00 (work in progress),
September 2017.
[I-D.ietf-6lo-blemesh]
Gomez, C., Darroudi, S., and T. Savolainen, "IPv6 Mesh
over BLUETOOTH(R) Low Energy using IPSP", draft-ietf-6lo-
blemesh-02 (work in progress), September 2017.
[I-D.satish-6tisch-6top-sf1] [I-D.satish-6tisch-6top-sf1]
Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S. Anamalamudi, S., Liu, B., Zhang, M., Sangi, A., Perkins,
Anand, "Scheduling Function One (SF1) for hop-by-hop C., and S. Anand, "Scheduling Function One (SF1): hop-by-
Scheduling in 6tisch Networks", draft-satish-6tisch-6top- hop Scheduling with RSVP-TE in 6tisch Networks", draft-
sf1-03 (work in progress), February 2017. satish-6tisch-6top-sf1-04 (work in progress), October
2017.
[I-D.hou-6lo-plc] [I-D.hou-6lo-plc]
Hou, J., Hong, Y., and X. Tang, "Transmission of IPv6 Hou, J., Hong, Y., and X. Tang, "Transmission of IPv6
Packets over PLC Networks", draft-hou-6lo-plc-01 (work in Packets over PLC Networks", draft-hou-6lo-plc-03 (work in
progress), June 2017. progress), December 2017.
[IETF_6lo] [IETF_6lo]
"IETF IPv6 over Networks of Resource-constrained Nodes "IETF IPv6 over Networks of Resource-constrained Nodes
(6lo) working group", (6lo) working group",
<https://datatracker.ietf.org/wg/6lo/charter/>. <https://datatracker.ietf.org/wg/6lo/charter/>.
[TIA-485-A]
"TIA, "Electrical Characteristics of Generators and
Receivers for Use in Balanced Digital Multipoint Systems",
TIA-485-A (Revision of TIA-485)", March 2003,
<https://global.ihs.com/
doc_detail.cfm?item_s_key=00032964>.
[G3-PLC] "G3-PLC Alliance", <http://www.g3-plc.com/home/>.
[NETRICITY]
"Netricity program in HomePlug Powerline Alliance",
<http://groups.homeplug.org/tech/Netricity>.
[G.9959] "International Telecommunication Union, "Short range [G.9959] "International Telecommunication Union, "Short range
narrow-band digital radiocommunication transceivers - PHY narrow-band digital radiocommunication transceivers - PHY
and MAC layer specifications", ITU-T Recommendation", and MAC layer specifications", ITU-T Recommendation",
January 2015. January 2015.
[G.9903] "International Telecommunication Union, "Narrowband
orthogonal frequency division multiplexing power line
communication transceivers for G3-PLC networks", ITU-T
Recommendation", August 2017.
[LTE_MTC] "3GPP TS 36.306 V13.0.0, 3rd Generation Partnership [LTE_MTC] "3GPP TS 36.306 V13.0.0, 3rd Generation Partnership
Project; Technical Specification Group Radio Access Project; Technical Specification Group Radio Access
Network; Evolved Universal Terrestrial Radio Access Network; Evolved Universal Terrestrial Radio Access
(E-UTRA); User Equipment (UE) radio access capabilities (E-UTRA); User Equipment (UE) radio access capabilities
(Release 13)", December 2015. (Release 13)", December 2015.
[IEEE1901] [IEEE1901]
"IEEE Standard, IEEE Std. 1901-2010 - IEEE Standard for "IEEE Standard, IEEE Std. 1901-2010 - IEEE Standard for
Broadband over Power Line Networks: Medium Access Control Broadband over Power Line Networks: Medium Access Control
and Physical Layer Specifications", 2010, and Physical Layer Specifications", 2010,
skipping to change at page 21, line 29 skipping to change at page 24, line 34
"IEEE Standard (work-in-progress), IEEE-SA Standards "IEEE Standard (work-in-progress), IEEE-SA Standards
Board", <http://sites.ieee.org/sagroups-1901-1/>. Board", <http://sites.ieee.org/sagroups-1901-1/>.
[IEEE1901.2] [IEEE1901.2]
"IEEE Standard, IEEE Std. 1901.2-2013 - IEEE Standard for "IEEE Standard, IEEE Std. 1901.2-2013 - IEEE Standard for
Low-Frequency (less than 500 kHz) Narrowband Power Line Low-Frequency (less than 500 kHz) Narrowband Power Line
Communications for Smart Grid Applications", 2013, Communications for Smart Grid Applications", 2013,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
standard/1901.2-2013.html>. standard/1901.2-2013.html>.
[BACnet] "ASHRAE, "BACnet-A Data Communication Protocol for
Building Automation and Control Networks", ANSI/ASHRAE
Standard 135-2016", January 2016,
<http://www.techstreet.com/ashrae/standards/
ashrae-135-2016?product_id=1918140#jumps>.
Appendix A. Other 6lo Use Case Examples Appendix A. Other 6lo Use Case Examples
A.1. Use case of ITU-T G.9959: Smart Home A.1. Use case of ITU-T G.9959: Smart Home
Z-Wave is one of the main technologies that may be used to enable Z-Wave is one of the main technologies that may be used to enable
smart home applications. Born as a proprietary technology, Z-Wave smart home applications. Born as a proprietary technology, Z-Wave
was specifically designed for this particular use case. Recently, was specifically designed for this particular use case. Recently,
the Z-Wave radio interface (physical and MAC layers) has been the Z-Wave radio interface (physical and MAC layers) has been
standardized as the ITU-T G.9959 specification. standardized as the ITU-T G.9959 specification.
skipping to change at page 22, line 41 skipping to change at page 26, line 5
transceiver. This device is in the coverage range of the Fixed Part transceiver. This device is in the coverage range of the Fixed Part
of the home. The Fixed Part can act as a router connected to the of the home. The Fixed Part can act as a router connected to the
Internet. This way, the smart meter can transmit electricity Internet. This way, the smart meter can transmit electricity
consumption readings through the DECT-ULE link with the Fixed Part, consumption readings through the DECT-ULE link with the Fixed Part,
and the latter can forward such readings to the utility company using and the latter can forward such readings to the utility company using
Wide Area Network (WAN) links. The meter can also receive queries Wide Area Network (WAN) links. The meter can also receive queries
from the utility company or from an advanced energy control system from the utility company or from an advanced energy control system
controlled by the user, which may also be connected to the Fixed Part controlled by the user, which may also be connected to the Fixed Part
via DECT-ULE. via DECT-ULE.
A.3. Use case of MS/TP: Management of District Heating A.3. Use case of MS/TP: Building Automation Networks
The key feature of MS/TP is it's ability to run on the same cabling The primary use case for IPv6 over MS/TP (6LoBAC) is in building
as BACnet and some use of ModBus, the defacto standard for low automation networks. [BACnet] is the open international standard
bandwith industry communication. Specially Modbus has been around protocol for building automation, and MS/TP is defined in [BACnet]
since the 1980 and is still the standard for talking to fans, heat Clause 9. MS/TP was designed to be a low cost multi-drop field bus
pumps, water purifying equipment and everything else delivering to inter-connect the most numerous elements (sensors and actuators)
electricity, clean water and ventilation. of a building automation network to their controllers. A key aspect
of 6LoBAC is that it is designed to co-exist with BACnet MS/TP on the
same link, easing the ultimate transition of some BACnet networks to
native end-to-end IPv6 transport protocols. New applications for
6LoBAC may be found in other domains where low cost, long distance,
and low latency are required.
Example: Use of MS/TP for management of district heating Example: Use of 6LoBAC in Building Automation Networks
The mechanical room in the cellar of an apartment building gets
district heating and electricity from the utility providers. The The majority of installations for MS/TP are for "terminal" or
room has a Supervisory Control And Data Acquisition (SCADA) computer "unitary" controllers, i.e. single zone or room controllers that may
talking to a centralized server and command center somewhere else connect to HVAC or other controls such as lighting or blinds. The
over IP, on the other hand it is controlling the heating, fans and economics of daisy-chaining a single twisted-pair between multiple
distribution panel over a 2-wire RS-485 based protocol to make sure devices is often preferred over home-run Cat-5 style wiring.
the logic controller for district heating keeps a constant
temperature at the tapwater, the logic controller for heat produktion A multi-zone controller might be implemented as an IP router between
keeps the right radiator temperature depending on the weather and the a traditional Ethernet link and several 6LoBAC links, fanning out to
fans have a correct speed and are switched off in case district multiple terminal controllers.
heating fails to prevent cooling out the building and give certain
commands in case smoke is detected. Speed is not important, in this The superior distance capabilities of MS/TP (~1 km) compared to other
usecase, 19,200 bit/s capable equipment is sold as high speed 6lo media may suggest its use in applications to connect remote
communication capable. Reliability is important, this not working devices to the nearest building infrastructure. for example, remote
will easily give millions of dollars of damage. Normally the setup pumping or measuring stations with moderate bandwidth requirements
is that the SCADA device asks a question to a specific controlling can benefit from the low cost and robust capabilities of MS/TP over
device, gets an answer from the controlling device, asks a new other wired technologies such as DSL, and without the line-of-site
question to some other device. restrictions or hop-by-hop latency of many low cost wireless
solutions.
A.4. Use case of NFC: Alternative Secure Transfer A.4. Use case of NFC: Alternative Secure Transfer
According to applications, various secured data can be handled and According to applications, various secured data can be handled and
transferred. Depending on security level of the data, methods for transferred. Depending on security level of the data, methods for
transfer can be alternatively selected. transfer can be alternatively selected.
Example: Use of NFC for Secure Transfer in Healthcare Services with Example: Use of NFC for Secure Transfer in Healthcare Services with
Tele-Assistance Tele-Assistance
skipping to change at page 25, line 23 skipping to change at page 28, line 36
information. In such scenarios, point-to-point traffic flows are information. In such scenarios, point-to-point traffic flows are
significant to exchange the controlled information in between sensors significant to exchange the controlled information in between sensors
and actuators within the constrained networks. and actuators within the constrained networks.
Example: Use of IEEE 802.15.4e for P2P communication in closed-loop Example: Use of IEEE 802.15.4e for P2P communication in closed-loop
application application
AODV-RPL [I-D.ietf-roll-aodv-rpl] is proposed as a standard P2P AODV-RPL [I-D.ietf-roll-aodv-rpl] is proposed as a standard P2P
routing protocol to provide the hop-by-hop data transmission in routing protocol to provide the hop-by-hop data transmission in
closed-loop constrained networks. Scheduling Functions i.e. SF0 closed-loop constrained networks. Scheduling Functions i.e. SF0
[I-D.ietf-6tisch-6top-sf0] and SF1 [I-D.satish-6tisch-6top-sf1] is [I-D.ietf-6tisch-6top-sfx] and SF1 [I-D.satish-6tisch-6top-sf1] is
proposed to provide distributed neighbor-to-neighbor and end-to-end proposed to provide distributed neighbor-to-neighbor and end-to-end
resource reservations, respectively for traffic flows in resource reservations, respectively for traffic flows in
deterministic networks (6TiSCH). deterministic networks (6TiSCH).
The potential scenarios that can make use of the end-to-end resource The potential scenarios that can make use of the end-to-end resource
reservations can be in health-care and industrial applications. reservations can be in health-care and industrial applications.
AODV-RPL and SF0/SF1 are the significant routing and resource AODV-RPL and SF0/SF1 are the significant routing and resource
reservation protocols for closed-loop applications in constrained reservation protocols for closed-loop applications in constrained
networks. networks.
 End of changes. 57 change blocks. 
170 lines changed or deleted 312 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/