< draft-ietf-6lo-use-cases-00.txt   draft-ietf-6lo-use-cases-01.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: June 1, 2017 UPC/i2cat Expires: September 13, 2017 UPC/i2cat
Y-H. Choi Y-H. Choi
ETRI ETRI
D-Y. Ko D-Y. Ko
SKtelecom SKtelecom
November 28, 2016 AR. Sangi
Huawei Technologies
Take. Aanstoot
Modio AB
March 12, 2017
IPv6 over Constrained Node Networks(6lo) Applicability & Use cases IPv6 over Constrained Node Networks(6lo) Applicability & Use cases
draft-ietf-6lo-use-cases-00 draft-ietf-6lo-use-cases-01
Abstract Abstract
This document describes the applicability of IPv6 over constrained This document describes the applicability of IPv6 over constrained
node networks (6lo) and use cases. It describes the practical node networks (6lo) and use cases. It describes the practical
deployment scenarios of 6lo technologies with the consideration of deployment scenarios of 6lo technologies with the consideration of
6lo link layer technologies and identifies the requirements. In 6lo link layer technologies and identifies the requirements. 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, LTE MTC, and IEEE ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, LTE MTC, PLC (IEEE
802.15.4e(6tisch) are widely used at constrained node networks for 1901), and IEEE 802.15.4e(6tisch) are widely used at constrained node
typical services. Based on these link layer technologies, IPv6 over networks for typical services. Based on these link layer
networks of resource-constrained nodes has various and practical use technologies, IPv6 over networks of resource-constrained nodes has
cases. To efficiently implement typical services, the applicability various and practical use cases. To efficiently implement typical
and consideration of several design space dimensions are described. services, the applicability and consideration of several design space
dimensions are described.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 13, 2017.
This Internet-Draft will expire on June 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . 4 3. 6lo Link layer technologies . . . . . . . . . . . . . . . . . 4
3.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4 3.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . 4 3.2. Bluetooth LE . . . . . . . . . . . . . . . . . . . . . . 4
3.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Master-Slave/Token-Passing . . . . . . . . . . . . . . . 5 3.4. MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6. LTE MTC . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. LTE MTC . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7. IEEE 802.15.4e . . . . . . . . . . . . . . . . . . . . . 7 3.7. PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 8 3.8. IEEE 802.15.4e . . . . . . . . . . . . . . . . . . . . . 8
5. Design Space . . . . . . . . . . . . . . . . . . . . . . . . 8 4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 9
6. 6lo Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Design Space . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 10 6. 6lo Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Use case of Bluetooth Low Energy: Smartphone-Based 6.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 11
Interaction with Constrained Devices . . . . . . . . . . 11 6.2. Use case of Bluetooth LE: Smartphone-Based Interaction
6.3. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 13 with Constrained Devices . . . . . . . . . . . . . . . . 13
6.4. Use case of MS/TP: . . . . . . . . . . . . . . . . . . . 14 6.3. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 14
6.5. Use case of NFC: Alternative Secure Transfer . . . . . . 14 6.4. Use case of MS/TP: Management of District Heating . . . . 15
6.6. Use case of LTE MTC . . . . . . . . . . . . . . . . . . . 16 6.5. Use case of NFC: Alternative Secure Transfer . . . . . . 17
6.7. Use case of IEEE 802.15.4e: . . . . . . . . . . . . . . . 18 6.6. Use case of LTE MTC: Gateway for Wireless Backhaul
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 Network . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6.7. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 6.8. Use case of IEEE 802.15.4e: Industrial Automation . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 27
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]. For example, because some IEEE 802.15.4 link devices [RFC4919]. For example, because 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, an appropriate fragmentation below to support an MTU of 1280 bytes, an appropriate fragmentation
and reassembly adaptation layer must be provided at the layer of and reassembly adaptation layer must be provided at the layer below
below IPv6. Also, the limited size of IEEE 802.15.4 frame and low IPv6. Also, the limited size of IEEE 802.15.4 frame and low energy
energy consumption requirements make the need for header compression. consumption requirements make the need for header compression. IETF
IETF 6lowpan (IPv6 over Low powerWPAN) working group published, an 6lowpan (IPv6 over Low powerWPAN) working group published, an
adaptation layer for sending IPv6 packets over IEEE 802.15.4 adaptation layer for sending IPv6 packets over IEEE 802.15.4
[RFC4944], compression format for IPv6 datagrams over IEEE [RFC4944], compression format for IPv6 datagrams over IEEE
802.15.4-based networks [RFC6282], and Neighbor Discovery 802.15.4-based networks [RFC6282], and Neighbor Discovery
Optimization for 6lowpan [RFC6775]. Optimization for 6lowpan [RFC6775].
As IoT (Internet of Things) services become more popular, various As IoT (Internet of Things) services become more popular, various
link layer technologies such as Bluetooth Low Energy (Bluetooth LE), link layer technologies such as Bluetooth Low Energy (Bluetooth LE),
ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications - ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications -
Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near
Field Communication (NFC), and LTE Machine Type Communication are Field Communication (NFC), Power Line Communication (PLC), and LTE
actively used. And the transmission of IPv6 packets over these link Machine Type Communication are actively used. And the transmission
layer technologies is required. A number of IPv6-over-foo documents of IPv6 packets over these link layer technologies is required. A
have been developed in the IETF 6lo (IPv6 over Networks of Resource- number of IPv6-over-foo documents have been developed in the IETF 6lo
constrained Nodes) and 6tisch (IPv6 over the TSCH mode of IEEE (IPv6 over Networks of Resource-constrained Nodes) and 6tisch (IPv6
802.15.4e) working groups. over the TSCH mode of IEEE 802.15.4e) working groups.
In the 6lowpan working group, the [RFC6568], "Design and Application In the 6lowpan 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. In this document, various design space dimensions area networks. In this document, various design space dimensions
such as deployment, network size, power source, connectivity, multi- such as deployment, network size, power source, connectivity, multi-
hop communication, traffic pattern, security level, mobility, and QoS hop communication, traffic pattern, security level, mobility, and QoS
were analyzed. And it described a fundamental set of 6lowpan were analyzed. And it described a fundamental set of 6lowpan
application scenarios and use cases: Industrial monitoring-Hospital application scenarios and use cases: Industrial monitoring-Hospital
storage rooms, Structural monitoring-Bridge safety monitoring, storage rooms, Structural monitoring-Bridge safety monitoring,
Connected home-Home Automation, Healthcare-Healthcare at home by Connected home-Home automation and Smart grid assistance, Healthcare-
tele-assistance, Vehicle telematics-telematics, and Agricultural Healthcare at home by tele-assistance, Vehicle telematics-telematics,
monitoring-Automated vineyard. and Agricultural monitoring-Automated vineyard.
Even though the [RFC6568] describes some potential application Even though the [RFC6568] describes some potential application
scenarios and use cases and it lists the design space in the context scenarios and use cases and it lists the design space in the context
of 6lowpan, it does not cover the different use cases and design of 6lowpan, it does not cover the different use cases and design
space in the context of the 6lo working group. The RFC6568 assumed space in the context of the 6lo working group. The [RFC6568] assumed
that the link layer technology is the IEEE802.15.4 and the described that the link layer technology is the IEEE802.15.4 and the described
application scenarios and use cases were based on the IEEE 802.15.4 application scenarios and use cases were based on the IEEE 802.15.4
technologies. Due to various link layer technologies such as ITU-T technologies. Due to various link layer technologies such as ITU-T
G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, LTE MTC, and IEEE G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, LTE MTC, Power Line
802.15.4e(6tisch), potential application scenarios and use cases of Communication (PLC), and IEEE 802.15.4e(6tisch), potential
6lo will go beyond the RFC6568. application scenarios and use cases of 6lo will go beyond the
[RFC6568].
This document provides the applicability and use cases of 6lo, This document provides the applicability and use cases of 6lo,
considering the following: 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. those of 6lowpan.
o 6lo applicability and use cases SHOULD cover various IoT related o 6lo applicability and use cases SHOULD cover various IoT related
wire/wireless link layer technologies providing practical wire/wireless link layer technologies providing practical
information of such technologies. information of such technologies.
o 6lo applicability and use cases SHOULD describe characteristics o 6lo applicability and use cases SHOULD describe characteristics
and typical use cases of each link layer technology, and then 6lo and typical use cases of each link layer technology, and then 6lo
skipping to change at page 4, line 41 skipping to change at page 4, line 45
3.1. ITU-T G.9959 3.1. ITU-T G.9959
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). 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]. IPv6 prefixes [RFC7428].
3.2. Bluetooth Low Energy 3.2. Bluetooth LE
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 Devices such as mobile phones, notebooks, tablets and other handheld
skipping to change at page 5, line 45 skipping to change at page 5, line 47
Control (DLC) provides multiplexing as well as segmentation and re- Control (DLC) provides multiplexing as well as segmentation and re-
assembly for larger packets from layers above. The DECT ULE layer assembly for larger packets from layers above. The DECT ULE layer
also implements per-message authentication and encryption. The DLC also implements per-message authentication and encryption. The DLC
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 [I-D.ietf-6lo-dect-ule]. been standardized for higher layers [I-D.ietf-6lo-dect-ule].
3.4. Master-Slave/Token-Passing 3.4. MS/TP
MS/TP is a contention-free access method for the RS-485 physical MS/TP is a contention-free access method for the RS-485 physical
layer, which is used extensively in building automation networks. layer, which is used extensively 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. Together with low data rates
and a small address space, these constraints are similar to those and a small address space, these constraints are similar to those
faced in 6LoWPAN networks and suggest some elements of that solution faced in 6lowpan networks and suggest some elements of that solution
might be leveraged. MS/TP differs significantly from 6LoWPAN in at might be leveraged. MS/TP differs significantly from 6lowpan in at
least three respects: a) MS/TP devices typically have a continuous least three aspects: a) MS/TP devices typically have a continuous
source of power, 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, recent changes to MS/TP provide support for large payloads,
eliminating the need for link-layer fragmentation and reassembly. eliminating the need for link-layer fragmentation and reassembly.
MS/TP is designed to enable multidrop networks over shielded twisted MS/TP is designed to enable multidrop networks over shielded twisted
pair wiring. It can support a data rate of 115,200 baud on segments pair wiring, although not according to standards, in lower speeds,
up to 1000 meters in length, or segments up to 1200 meters in length normally 9600 bit/s, re-purposed telecom wiring is widely in use,
at lower baud rates. An MS/TP link requires only a UART, an RS-485 keeping deployment cost down. It can support a data rate of 115,200
transceiver with a driver that can be disabled, and a 5ms resolution baud on segments up to 1000 meters in length, or segments up to 1200
timer. These features make MS/TP a cost-effective field bus for the meters in length at lower baud rates. An MS/TP link requires only a
most numerous and least expensive devices in a building automation UART, an RS-485 transceiver with a driver that can be disabled, and a
network [I-D.ietf-6lo-6lobac]. 5ms resolution timer. These features make MS/TP a cost-effective and
very reliable field bus for the most numerous and least expensive
devices in a building automation network [I-D.ietf-6lo-6lobac].
3.5. NFC 3.5. NFC
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 7, line 8 skipping to change at page 7, line 16
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 1
UE and category 2 UE are 10.3 Mbit/s and 51.0 Mbit/s respectively. 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 standard. 3GPP standards defined the
category 0 to be used for low rate IoT service in release 12. Since category 0 to be used for low rate IoT service in release 12. Since
category 1 and category 0 could be used for low rate IoT service, category 1 and category 0 could be used for low rate IoT service,
these categories are called LTE MTC (Machine Type Communication) these categories are called LTE MTC (Machine Type Communication)
[LTE_MTC]. [LTE_MTC].
LTE MTC have the advantages compared to above category 2 to be used LTE MTC offer advantages in comparison to above category 2 and is
for low rate IoT service such as low power and low cost. appropriate to be used for low rate IoT services such as low power
and low cost.
The below figure shows the primary characteristics of LTE MTC. The below figure shows the primary characteristics of LTE MTC.
+------------+---------------------+-------------------+ +------------+---------------------+-------------------+
| Category | Max. Date Rate Down | Max. Date Rate Up | | Category | Max. Data Rate Down | Max. Data Rate Up |
+------------+---------------------+-------------------+ +------------+---------------------+-------------------+
| Category 0 | 1.0 Mbit/s | 1.0 Mbit/s | | Category 0 | 1.0 Mbit/s | 1.0 Mbit/s |
| | | | | | | |
| Category 1 | 10.3 Mbit/s | 5.2 Mbit/s | | Category 1 | 10.3 Mbit/s | 5.2 Mbit/s |
+------------+---------------------+-------------------+ +------------+---------------------+-------------------+
Table 1: Primary characteristics of LTE MTC Table 1: Primary characteristics of LTE MTC
3.7. IEEE 802.15.4e 3.7. PLC
Unlike other dedicated communication infrastructure, the required
medium (power conductor) is widely available indoors and outdoors.
Moreover, wire d technologies are more susceptible to cause
interference but are more rel iable than their wireless counterparts.
PLC is a data transmission techniq ue that utilizes power conductors
as medium.
The below figure shows some available open standards defining PLC.
+-------------+-----------------+------------+-----------+----------+
| PLC Systems | Frequency Range | Type | Data Rate | Distance |
+-------------+-----------------+------------+-----------+----------+
| IEEE1901 | <100MHz | Broadband | 200Mbps | 1000m |
| | | | | |
| IEEE1901.1 | <15MHz | PLC-IoT | 10Mbps | 2000m |
| | | | | |
| IEEE1901.2 | <500kHz | Narrowband | 200Kbps | 3000m |
+-------------+-----------------+------------+-----------+----------+
Table 2: Some Available Open Standards in PLC
[IEEE1901] defines broadband variant of PLC but is effective within
short range. This standard addresses the requirements of
applications with high data rate such as: Internet, HDTV, Audio,
Gaming etc. Broadband operates on OFDM (Orthogonal Frequency
Division Multiplexing) modulation.
[IEEE1901.2] defines narrowband variant of PLC with less data rate
but significantly higher transmission range that could be used in an
indoor or even an outdoor environment. It supports operating either
in Low Voltage (LV) or High Voltage (HV) segment of PLC domain. It
is applicable to typical IoT applications such as: Building
Automation, Renewable Energy, Advanced Metering, Street Lighting,
Electric Vehicle, Smart Grid etc. Narrowband operates either on FSK
(Frequency Shift Keying), S (Spread) FSK, BPSK (Binary Phase Shift
Keying), SS (Spread Spectrum) or OFDM modulation. 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. [RFC8036].
Specific applications come with requirement of diversity. Although
IEEE1901 offers higher data rate but is not applicable for long
distance scenario due to losses in higher frequencies. On the other
hand, IEEE1901.2 is not applicable for real-time services due to low
data rate. The IEEE 1901.1 WG is working on a new standard, namely
[IEEE1901.1], that provides extended transmission range as compared
to IEEE1901 and higher data rate than IEEE1901.2 [IEEE1901.2]. More
intelligent IoT financial services are emerging such as: Self Service
Terminal, Bank Transfer, Scratch Card, POS (point of sale) etc. and
require extensive data transfers. This standard is also known as
PLC-IoT and operates on OFDM modulation e.g. FTT (Fast Fourier
Transform) and/or wavelet OFDM.
3.8. IEEE 802.15.4e
The Timeslotted Channel Hopping (TSCH) mode was introduced in the The Timeslotted 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.
All the communication in the network is orchestrated by a All the communication in the network is orchestrated by a
communication schedule which indicates to each node what to do in communication schedule which indicates to each node what to do in
each of the timeslots of a slotframe: transmit, listen or sleep. The each of the timeslots of a slotframe: transmit, listen or sleep. The
communication schedule can be built so that the right amount of link- communication schedule can be built so that the right amount of link-
layer resources (the cells in the schedule) are scheduled to satisfy layer resources (the cells in the schedule) are scheduled to satisfy
the communication needs of the applications running on the network, the communication needs of the applications running on the network,
while keeping the energy consumption of the nodes very low. Cells while keeping the energy consumption of the nodes very low. Cells
can be scheduled in a collision-free way, introducing a high level of can be scheduled in a collision-free way, introducing a high level of
determinism to the network. determinism to the network.
A TSCH network exploits channel hopping: subsequent packets exchanged A TSCH network exploits channel hopping: subsequent packets exchanged
between neighbor nodes are done so on a different frequency. This between neighbor nodes are done on a different frequency. This means
means that, if a frame isn't received, the transmitter node will re- that, if a frame isn't received, the transmitter node will re-
transmitt the frame on a different frequency. The resulting "channel transmitt the frame on a different frequency. The resulting "channel
hopping" efficiently combats external interference and multi-path hopping" efficiently combats external interference and multi-path
fading. fading.
The main benefits of IEEE 802.15.4 TSCH are: The main benefits of IEEE 802.15.4 TSCH are:
- ultra high reliability. Off-the-shelf commercial products offer - ultra high reliability. Off-the-shelf commercial products offer
over 99.999% end-to-end reliability. over 99.999% end-to-end reliability.
- ultra low-power consumption. Off-the-shelf commercial products - ultra low-power consumption. Off-the-shelf commercial products
offer over a decade of battery lifetime. offer over a decade of battery lifetime.
4. 6lo Deployment Scenarios 4. 6lo Deployment Scenarios
In this clause, we will describe some 6lo deployment scenrios such as In this clause, we will describe some 6lo deployment scenarios such
Smart Grid activity in WiSun as Smart Grid activity in WiSun
[TBD] [TBD]
5. Design Space 5. Design Space
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 the RFC 6568, the following design space dimensions are rate). In the RFC 6568, the following design space dimensions are
described; Deployment, Network size, Power source, Connectivity, described; Deployment, Network size, Power source, Connectivity,
Multi-hop communication, Traffic pattern, Mobility, Quality of Multi-hop communication, Traffic pattern, Mobility, Quality of
Service (QoS). Service (QoS).
The design space dimensions of 6lo are a little different from those The design space dimensions of 6lo are a little different from those
of the RFC 6568 due to the different characteristics of 6lo link of the RFC 6568 due to the different characteristics of 6lo link
layer technologies. The following design space dimensions can be layer technologies. The following design space dimensions can be
skipping to change at page 9, line 45 skipping to change at page 11, line 20
o Security Bootstrapping: Without the external operations, 6lo nodes o Security Bootstrapping: Without the external operations, 6lo nodes
must have the security bootstrapping mechanism. must have the security bootstrapping mechanism.
o Power use strategy: to enable certain use cases, there may be o Power use strategy: to enable certain use cases, there may be
requirements on the class of energy availability and the strategy requirements on the class of energy availability and the strategy
followed for using power for communication [RFC7228]. Each link followed for using power for communication [RFC7228]. Each link
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 RFC 7228 terminology. to be familiar with RFC 7228 terminology.
o Update firmware requirements: Most 6lo uses case 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.
6. 6lo Use Cases 6. 6lo Use Cases
6.1. Use case of ITU-T G.9959: Smart Home 6.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 use case. Recently, the Z-Wave was specifically designed for this particular use case. Recently,
radio interface (physical and MAC layers) has been standardized as the Z-Wave radio interface (physical and MAC layers) has been
the ITU-T G.9959 specification. standardized as the ITU-T G.9959 specification.
Example: Use of ITU-T G.9959 for Home Automation Example: Use of ITU-T G.9959 for Home Automation
Variety of home devices (e.g. light dimmers/switches, plugs, Variety of home devices (e.g. light dimmers/switches, plugs,
thermostats, blinds/curtains and remote controls) are augmented with thermostats, blinds/curtains and remote controls) are augmented with
ITU-T G.9959 interfaces. A user may turn on/off or may control home ITU-T G.9959 interfaces. A user may turn on/off or may control home
appliances by pressing a wall switch or by pressing a button in a appliances by pressing a wall switch or by pressing a button in a
remote control. Scenes may be programmed, so that after a given remote control. Scenes may be programmed, so that after a given
event, the home devices adopt a specific configuration. Sensors may event, the home devices adopt a specific configuration. Sensors may
also periodically send measurements of several parameters (e.g. gas also periodically send measurements of several parameters (e.g. gas
skipping to change at page 10, line 38 skipping to change at page 12, line 9
The devices involved in the described scenario are nodes of a network The devices involved in the described scenario are nodes of a network
that follows the mesh topology, which is suitable for path diversity that follows the mesh topology, which is suitable for path diversity
to face indoor multipath propagation issues. The multihop paradigm to face indoor multipath propagation issues. The multihop paradigm
allows end-to-end connectivity when direct range communication is not allows end-to-end connectivity when direct range communication is not
possible. Security support is required, specially for safety-related possible. Security support is required, specially for safety-related
communication. When a user interaction (e.g. a button press) communication. When a user interaction (e.g. a button press)
triggers a message that encapsulates a command, if the message is triggers a message that encapsulates a command, if the message is
lost, the user may have to perform further interactions to achieve lost, the user may have to perform further interactions to achieve
the desired effect (e.g. a light is turned off). A reaction to a the desired effect (e.g. a light is turned off). A reaction to a
user interaction will be perceived by the user as immediate as long user interaction will be perceived by the user as immediate as long
as the reaction takes place after less than 0.5 seconds [RFC5826]. as the reaction takes place within 0.5 seconds [RFC5826].
Dominant parameters in home automation scenarios with ITU-T G.9959: Dominant parameters in home automation scenarios with ITU-T G.9959:
o Deployment/Bootstrapping: Pre-planned. o Deployment/Bootstrapping: Pre-planned.
o Topology: Mesh topology. o Topology: Mesh topology.
o L2-mesh or L3-mesh: ITU-T G.9959 provides support for L2-mesh, and o L2-mesh or L3-mesh: ITU-T G.9959 provides support for L2-mesh, and
L3-mesh can also be used (the latter requires an IP-based routing L3-mesh can also be used (the latter requires an IP-based routing
protocol). protocol).
skipping to change at page 11, line 29 skipping to change at page 13, line 5
o Traffic patterns: Periodic (sensor readings) and aperiodic (user- o Traffic patterns: Periodic (sensor readings) and aperiodic (user-
triggered interaction). triggered interaction).
o Security Bootstrapping: Required. o Security Bootstrapping: Required.
o Power use strategy: Mix of P1 (Low-power) devices and P9 (Always- o Power use strategy: Mix of P1 (Low-power) devices and P9 (Always-
on) devices. on) devices.
o Update firmware requirements: TBD. o Update firmware requirements: TBD.
6.2. Use case of Bluetooth Low Energy: Smartphone-Based Interaction 6.2. Use case of Bluetooth LE: Smartphone-Based Interaction with
with Constrained Devices Constrained Devices
The key feature behind the current high Bluetooth LE momentum is its The key feature behind the current high Bluetooth LE momentum is its
support in a large majority of smartphones in the market. Bluetooth support in a large majority of smartphones in the market. Bluetooth
LE can be used to allow the interaction between the smartphone and LE can be used to allow the interaction between the smartphone and
surrounding sensors or actuators. Furthermore, Bluetooth LE is also surrounding sensors or actuators. Furthermore, Bluetooth LE is also
the main radio interface currently available in wearables. Since a the main radio interface currently available in wearables. Since a
smartphone typically has several radio interfaces that provide smartphone typically has several radio interfaces that provide
Internet access, such as Wi-Fi or 4G, the smartphone can act as a Internet access, such as Wi-Fi or 4G, the smartphone can act as a
gateway for nearby devices such as sensors, actuators or wearables. gateway for nearby devices such as sensors, actuators or wearables.
Bluetooth LE may be used in several domains, including healthcare, Bluetooth LE may be used in several domains, including healthcare,
sports/wellness and home automation. sports/wellness and home automation.
Example: Bluetooth LE-based Body Area Network for fitness Example: Use of Bluetooth LE-based Body Area Network for fitness
A person wears a smartwatch for fitness purposes. The smartwatch has A person wears a smartwatch for fitness purposes. The smartwatch has
several sensors (e.g. heart rate, accelerometer, gyrometer, GPS, several sensors (e.g. heart rate, accelerometer, gyrometer, GPS,
temperature, etc.), a display, and a Bluetooth LE radio interface. temperature, etc.), a display, and a Bluetooth LE radio interface.
The smartwatch can show fitness-related statistics on its display. The smartwatch can show fitness-related statistics on its display.
However, when a paired smartphone is in the range of the smartwatch, However, when a paired smartphone is in the range of the smartwatch,
the latter can report almost real-time measurements of its sensors to 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 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
skipping to change at page 13, line 16 skipping to change at page 14, line 40
DECT is a technology widely used for wireless telephone DECT is a technology widely used for wireless telephone
communications in residential scenarios. Since DECT-ULE is a low- communications in residential scenarios. Since DECT-ULE is a low-
power variant of DECT, DECT-ULE can be used to connect constrained power variant of DECT, DECT-ULE can be used to connect constrained
devices such as sensors and actuators to a Fixed Part, a device that devices such as sensors and actuators to a Fixed Part, a device that
typically acts as a base station for wireless telephones. Therefore, typically acts as a base station for wireless telephones. Therefore,
DECT-ULE is specially suitable for the connected home space in DECT-ULE is specially suitable for the connected home space in
application areas such as home automation, smart metering, safety, application areas such as home automation, smart metering, safety,
healthcare, etc. healthcare, etc.
Example: use of DECT-ULE for Smart Metering Example: Use of DECT-ULE for Smart Metering
The smart electricity meter of a home is equipped with a DECT-ULE The smart electricity meter of a home is equipped with a DECT-ULE
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
skipping to change at page 13, line 51 skipping to change at page 15, line 27
o Buffering requirements: Low requirement. o Buffering requirements: Low requirement.
o Security requirements: Data privacy and security must be provided. o Security requirements: Data privacy and security must be provided.
Encryption is required. Encryption is required.
o Mobility: No. o Mobility: No.
o Time Synchronization: TBD. o Time Synchronization: TBD.
o Reliability and QoS: bounded latency, stringent reliability o Reliability and QoS: bounded latency, stringent reliability
service agreements [I-D.ietf-roll-applicability-ami]. service agreements [RFC8036].
o Traffic patterns: Periodic (meter reading notifications sent by o Traffic patterns: Periodic (meter reading notifications sent by
the meter) and aperiodic (user- or company-triggered queries to the meter) and aperiodic (user- or company-triggered queries to
the meter, and messages triggered by local events such as power the meter, and messages triggered by local events such as power
outage or leak detection [I-D.ietf-roll-applicability-ami]). outage or leak detection [RFC8036].
o Security Bootstrapping: required. o Security Bootstrapping: required.
o Power use strategy: P0 (Normally-off) for devices with long sleep o Power use strategy: P0 (Normally-off) for devices with long sleep
intervals (i.e. greater than ~10 seconds) which then may need to intervals (i.e. greater than ~10 seconds) which then may need to
resynchronize again, and P1 (Low-power) for short sleep intervals. resynchronize again, and P1 (Low-power) for short sleep intervals.
P9 (Always-on) for the Fixed Part (FP), which is the central node P9 (Always-on) for the Fixed Part (FP), which is the central node
in the star topology. in the star topology.
o Update firmware requirements: TBD. o Update firmware requirements: TBD.
6.4. Use case of MS/TP: 6.4. Use case of MS/TP: Management of District Heating
[TBD] The key feature of MS/TP is it's ability to run on the same cabling
as BACnet and some use of ModBus, the defacto standard for low
bandwith industry communication. Specially Modbus has been around
since the 1980 and is still the standard for talking to fans, heat
pumps, water purifying equipment and everything else delivering
electricity, clean water and ventilation.
Example: [TBD] Example: Use of MS/TP for management of district heating
o Power use strategy: P9 (Always-on). The mechanical room in the cellar of an apartment building gets
district heating and electricity from the utility providers. The
room has a Supervisory Control And Data Acquisition (SCADA) computer
talking to a centralized server and command center somewhere else
over IP, on the other hand it is controlling the heating, fans and
distribution panel over a 2-wire RS-485 based protocol to make sure
the logic controller for district heating keeps a constant
temperature at the tapwater, the logic controller for heat produktion
keeps the right radiator temperature depending on the weather and the
fans have a correct speed and are switched off in case district
heating fails to prevent cooling out the building and give certain
commands in case smoke is detected. Speed is not important, in this
usecase, 19,200 bit/s capable equipment is sold as high speed
communication capable. Reliability is important, this not working
will easily give millions of dollars of damage. Normally the setup
is that the SCADA device asks a question to a specific controlling
device, gets an answer from the controlling device, asks a new
question to some other device.
o Deployment/Bootstrapping: Pre-planned.
o Topology: Bus, master-slave, token-passing.
o Multi-link subnet, single subnet: [TBD], normally single.
o Data rate: Small data rate, frequent transmissions.
o Buffering requirements: Low.
o Security requirements: Security must be provided, authentication
is a must.
o Mobility: Highly static
o Time synchronization: Required.
o Reliability and QOS: High, Alerts have to arrive properly, timing
is not important. Implication of failing reliability has high
probability for life-or-death implications (fire-alarms) or
millions of dollars of liability (frozen water heating system in a
high rise building)
o Traffic patterns: Constant sensor readings and asking devices for
error reporting.
o Security Bootstrapping: Nice to have, not very important.
o Power use strategy: P9
o Update firmware requirements: Required.
6.5. Use case of NFC: Alternative Secure Transfer 6.5. 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. The personal data having transfer can be alternatively selected. The personal data having
serious issues should be transferred securely, but data transfer by serious issues should be transferred securely, but data transfer by
using Wi-Fi and Bluetooth connections cannot always be secure because using Wi-Fi and Bluetooth connections cannot always be secure because
of their a little long radio frequency range. Hackers can overhear of their a little long radio frequency range. Hackers can overhear
the personal data transfer behind hidden areas. Therefore, methods the personal data transfer behind hidden areas. Therefore, methods
need to be alternatively selected to transfer secured data. Voice need to be alternatively selected to transfer secured data. Voice
and video data, which are not respectively secure and requires long and video data, which are not respectively secure and requires long
transmission range, can be transferred by 3G/4G technologies, such as transmission range, can be transferred by 3G/4G technologies, such as
WCDMA, GSM, and LTE. Big size data, which are not secure and WCDMA, GSM, and LTE. Big size data, which are not secure and
requires high speed and broad bandwidth, can be transferred by Wi-Fi requires high speed and broad bandwidth, can be transferred by Wi-Fi
and wired network technologies. However, the personal data, which and wired network technologies. However, the personal data, which
pose serious issues if mishandled while transferred in wireless pose serious issues if mishandled while transferred in wireless
domain, can be securely transferred by NFC technology. It has very domain, can be securely transferred by NFC technology. It has very
short frequency range - nearly single touch communication. short frequency range - nearly single touch communication.
Example: Secure Transfer by Using NFC in Healthcare Services with Example: Use of NFC for Secure Transfer in Healthcare Services with
Tele-Assistance Tele-Assistance
A senior citizen who lives alone wears one to several wearable 6lo A senior citizen who lives alone wears one to several wearable 6lo
devices to measure heartbeat, pulse rate, etc. The 6lo devices are devices to measure heartbeat, pulse rate, etc. The 6lo devices are
densely installed at home for movement detection. An LoWPAN Border densely installed at home for movement detection. An LoWPAN Border
Router (LBR) at home will send the sensed information to a connected Router (LBR) at home will send the sensed information to a connected
healthcare center. Portable base stations with LCDs may be used to healthcare center. Portable base stations with LCDs may be used to
check the data at home, as well. Data is gathered in both periodic check the data at home, as well. Data is gathered in both periodic
and event-driven fashion. In this application, event-driven data can and event-driven fashion. In this application, event-driven data can
be very time-critical. In addition, privacy also becomes a serious be very time-critical. In addition, privacy also becomes a serious
skipping to change at page 16, line 27 skipping to change at page 19, line 12
non-technical end-users. Real-time data acquisition and analysis non-technical end-users. Real-time data acquisition and analysis
are important. Efficient data management is needed for various are important. Efficient data management is needed for various
devices that have different duty cycles, and for role-based data devices that have different duty cycles, and for role-based data
control. Reliability and robustness of the network are also control. Reliability and robustness of the network are also
essential. essential.
o Power use strategy: TBD. o Power use strategy: TBD.
o Update firmware requirements: TBD. o Update firmware requirements: TBD.
6.6. Use case of LTE MTC 6.6. Use case of LTE MTC: Gateway for Wireless Backhaul Network
Wireless link layer technologies can be divided into short range Wireless link layer technologies can be divided into short range
connectivity and long range connectivity. BLE, ITU-T G.9959 connectivity and long range connectivity. BLE, ITU-T G.9959
(Z-Wave), DECT-ULE, MS/TP, NFC are used for short range connectivity. (Z-Wave), DECT-ULE, MS/TP, NFC are used for short range connectivity.
LTE MTC is used for long range connectivity. And there is another LTE MTC is used for long range connectivity. And there is another
long range connectivity technology. It is LPWAN (Low Power Wide Area long range connectivity technology. It is LPWAN (Low Power Wide Area
Network) technology such as LoRa, Sigfox, etc. Therefore, the use Network) technology such as LoRa, Sigfox, Wi-Sun etc. Therefore, the
case of LTE MTC could be used in LPWAN. use case of LTE MTC could be used in LPWAN.
Example: Use of wireless backhaul for LoRa gateway Example: Use of LTE MTC for LoRa gateway
LoRa is one of the most promising technologies of LPWAN. LoRa LoRa is one of the most promising technology of LPWAN. LoRa network
network architecture has a star of star topology. LoRa gateway relay architecture has a star of star topology. LoRa gateway relay the
the messages from LoRa end device to application server and vice messages from LoRa end device to application server and vice versa.
versa. LoRa gateway can has two types of backhaul, wired and LoRa gateway can have two types of backhaul, wired and wireless
wireless backhaul. backhaul.
If LoRa gateway has wireless backhaul, it should have LTE modem. If a LoRa gateway has wireless backhaul, it should have LTE modem.
Since the modem cost of LTE MTC is cheaper than the modem cost of Since the modem cost of LTE MTC is cheaper than the modem cost of
above LTE category 2, it is helpful to design to use LTE MTC. Since above LTE category 2, it is helpful to design to use LTE MTC.
the maximum date rate of LoRa end device is 50kbps, it is sufficient Moreover, the maximum date rate of LoRa end device is 50kbps, it is
to use LTE MTC without using category 2. sufficient to use LTE MTC without using category 2.
Dominant parameters in LoRa gateway scenarios with above example: Dominant parameters in LoRa gateway scenarios in above example:
o Deployment/Bootstrapping: Pre-planned. o Deployment/Bootstrapping: Pre-planned.
o Topology: Star topology. o Topology: Star topology.
o L2-mesh or L3-mesh: No. o L2-mesh or L3-mesh: No.
o Multi-link subnet, single subnet: Single subnet. o Multi-link subnet, single subnet: Single subnet.
o Data rate: depends on 3GPP specification. o Data rate: Depends on 3GPP specification.
o Buffering requirements: High requirement. o Buffering requirements: High requirement.
o Security requirements: No, because data security is already o Security requirements: No, because data security is already
provided in LoRa specification. provided in LoRa specification.
o Mobility: Static. o Mobility: Static.
o Time Synchronization: Highly required. o Time Synchronization: Highly required.
o Reliability and QoS: TBD. o Reliability and QoS: TBD.
o Traffic patterns: Random. o Traffic patterns: Random.
o Security Bootstrapping: required. o Security Bootstrapping: Required.
o Power use strategy: P9 (Always-on). o Power use strategy: P9 (Always-on).
o Update firmware requirements: TBD. o Update firmware requirements: TBD.
Example: Use of controlling car Example: Use of LTE MTC for controlling car
Car sharing services are becoming more popular. Customers wish to Car sharing services are becoming more popular. Customers wish to
control the car with smart phone application. For example, customers control the car with smart phone application. For example, customers
wish to lock/unlock the car door with smart phone application, wish to lock/unlock the car door with smart phone application,
because customers may not have a car key. Customers wish to blow because customers may not have a car key. Customers wish to blow
with smart phone application to locate the car easily. with smart phone application to locate the car easily.
Therefore, rental car should have a long range connectivity capable Therefore, rental car should have a long range connectivity capable
modem such as LoRa end device and LTE UE. However, LoRa may not be modem such as LoRa end device and LTE UE. However, LoRa may not be
used because LoRa has low reliability and may not be supported in an used because LoRa has low reliability and may not be supported in an
indoor environment such as a basement parking lot. And since message indoor environment such as a basement parking lot. And since message
size for car control is very small, it is sufficient to use LTE MTC size for car control is very small, it is sufficient to use LTE MTC
but category 2. instead of category 2.
Dominant parameters in controlling car scenarios with above example: Dominant parameters in controlling car scenarios in above example:
o Deployment/Bootstrapping: Pre-planned. o Deployment/Bootstrapping: Pre-planned.
o Topology: Star topology. o Topology: Star topology.
o L2-mesh or L3-mesh: No. o L2-mesh or L3-mesh: No.
o Multi-link subnet, single subnet: Single subnet. o Multi-link subnet, single subnet: Single subnet.
o Data rate: depends on 3GPP specification. o Data rate: Depends on 3GPP specification.
o Buffering requirements: High requirement. o Buffering requirements: High requirement.
o Security requirements: High requirement. o Security requirements: High requirement.
o Mobility: Always dynamic . o Mobility: Always dynamic .
o Time Synchronization: Highly required. o Time Synchronization: Highly required.
o Reliability and QoS: TBD. o Reliability and QoS: TBD.
o Traffic patterns: Random. o Traffic patterns: Random.
o Security Bootstrapping: required. o Security Bootstrapping: Required.
o Power use strategy: P1 (Low-power). o Power use strategy: P1 (Low-power).
6.7. Use case of IEEE 802.15.4e: 6.7. Use case of PLC: Smart Grid
[TBD] Smart grid concept is based on numerous operational and energy
measuring sub-systems of an electric grid. It comprises of multiple
administrative levels/segments to provide connectivity among these
numerous components. Last mile connectivity is established over LV
segment, whereas connectivity over electricity distribution takes
place in HV segment.
Example: [TBD] Although other wired and wireless technologies are also used in Smart
Grid (Advance Metering Infrastructure - AMI, Demand Response - DR,
Home Energy Management System - HEMS, Wide Area Situational Awareness
- WASA etc), PLC enjoys the advantage of existing (power conductor)
medium and better reliable data communication. PLC is a promising
wired communication technology in that the electrical power lines are
already there and the deployment cost can be comparable to wireless
technologies. The 6lo related scenarios lie in the low voltage PLC
networks with most applications in the area of Advanced Metering
Infrastructure, Vehicle-to-Grid communications, in-home energy
management and smart street lighting.
Example: Use of PLC for Advanced Metering Infrastructure
Household electricity meters transmit time-based data of electric
power consumption through PLC. Data concentrators receive all the
meter data in their corresponding living districts and send them to
the Meter Data Management System (MDMS) through WAN network (e.g.
Medium-Voltage PLC, Ethernet or GPRS) for storage and analysis. Two-
way communications are enabled which means smart meters can do
actions like notification of electricity charges according to the
commands from the utility company.
With the existing power line infrastructure as communication medium,
cost on building up the PLC network is naturally saved, and more
importantly, labor operational costs can be minimized from a long-
term perspective. Furthermore, this AMI application speeds up
electricity charge, reduces losses by restraining power theft and
helps to manage the health of the grid based on line loss analysis.
Dominant parameters in smart grid scenarios with PLC:
o Deployment/Bootstrapping: Pre-planned.
o Topology: Tree topology.
o L2-mesh or L3-mesh: No.
o Multi-link subnet, single subnet: Single subnet.
o Data rate: Small data rate, infrequent transmissions.
o Buffering requirements: Low requirement.
o Security requirements: Data privacy and security must be provided.
Encryption is required.
o Mobility: Static.
o Time Synchronization: Low requirement.
o Reliability and QoS: a relatively low ratio of message losses is
acceptable for periodic meter readings.
o Traffic patterns: Periodic (upstream meter reading notifications
sent by the meter) and aperiodic (utility company-triggered
downstream queries and messages to the meter such as notification
of electricity charges or leak detection).
o Security Bootstrapping: Required.
o Power use strategy: Mix of P1 (Low Power) devices and P9 (Always-
on) devices.
o Update firmware requirements: TBD.
Example: Use of PLC (IEEE1901.1) for WASA in Smart Grid
Many sub-systems of Smart Grid require low data rate and narrowband
variant (IEEE1901.2) of PLC fulfils such requirements. Recently,
more complex scenarios are emerging that require higher data rates.
(see Table 3).
+--------------+----------+--------------+-------------+---------+
| Sub System | Security | Bandwidth | Reliability | Latency |
+--------------+----------+--------------+-------------+---------+
| HEMS | High | 9.6-56kbps | 99% | <2000ms |
| | | | | |
| AMI-Node | High | 10-100kbps | 99% | <200ms |
| | | | | |
| AMI-Backhaul | High | 500kbps | 99% | <200ms |
| | | | | |
| WASA | High | 600-1500kbps | 99% | <200ms |
+--------------+----------+--------------+-------------+---------+
Table 3: Some Sub Systems of Smart Grid
WASA sub-system is an appropriate example that collects large amount
of information about the current state of the grid over wide area
from electric substations as well as power transmission lines. The
collected feedback is used for monitoring, controlling and protecting
all the sub-systems.
Dominant parameters in WASA scenario with above example:
o Deployment/Bootstrapping: Pre-planned.
o Topology: TBD.
o L2-mesh or L3-mesh: TBD.
o Multi-link subnet, single subnet: TBD.
o Data rate: TBD.
o Buffering requirements: TBD.
o Security requirements: TBD.
o Mobility: TBD.
o Time Synchronization: TBD.
o Reliability and QoS: TBD.
o Traffic patterns: TBD.
o Security Bootstrapping: TBD.
o Power use strategy: P9 (Always-on).
o Update firmware requirements: TBD.
6.8. Use case of IEEE 802.15.4e: Industrial Automation
Typical scenario of Industrial Automation where sensor and actuators
are connected through the time-slotted radio access (IEEE 802.15.4e).
For that, there will be a point-to-point control signal exchange in
between sensors and actuators to trigger the critical control
information. In such scenarios, point-to-point traffic flows are
significant to exchange the controlled information in between sensors
and actuators within the constrained networks.
Example: Use of IEEE 802.15.4e for P2P communication in closed-loop
application
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
closed-loop constrained networks. Scheduling Functions i.e. SF0
[I-D.ietf-6tisch-6top-sf0] and SF1 [I-D.satish-6tisch-6top-sf1] is
proposed to provide distributed neighbor-to-neighbor and end-to-end
resource reservations, respectively for traffic flows in
deterministic networks (6TiSCH).
The potential scenarios that can make use of the end-to-end resource
reservations can be in health-care and industrial applications.
AODV-RPL and SF0/SF1 are the significant routing and resource
reservation protocols for closed-loop applications in constrained
networks.
Dominant parameters in P2P scenarios with above example:
o Deployment/Bootstrapping: Pre-planned.
o Topology: TBD.
o L2-mesh or L3-mesh: TBD.
o Multi-link subnet, single subnet: TBD.
o Data rate: TBD.
o Buffering requirements: TBD.
o Security requirements: TBD.
o Mobility: TBD.
o Time Synchronization: TBD.
o Reliability and QoS: TBD.
o Traffic patterns: TBD.
o Security Bootstrapping: TBD.
o Power use strategy: P9 (Always-on).
o Update firmware requirements: TBD.
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
[TBD] [TBD]
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 (Ministerio de Educacion, Cultura y Deporte) through the Jose
Castillejo grant CAS15/00336. His contribution to this work has been Castillejo grant CAS15/00336. 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.
Samita Chakrabarti, Thomas Watteyne, Pascal Thubert, Abdur Rashid Samita Chakrabarti, Thomas Watteyne, Pascal Thubert, Xavier
Sangi, Xavier Vilajosana, Daniel Migault, and Take Aanstoot have Vilajosana, Daniel Migault, and Jianqiang HOU have provided valuable
provided valuable feedback for this draft. feedback 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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 20, line 20 skipping to change at page 26, line 47
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
over ITU-T G.9959 Networks", RFC 7428, over ITU-T G.9959 Networks", RFC 7428,
DOI 10.17487/RFC7428, February 2015, DOI 10.17487/RFC7428, February 2015,
<http://www.rfc-editor.org/info/rfc7428>. <http://www.rfc-editor.org/info/rfc7428>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<http://www.rfc-editor.org/info/rfc7668>. <http://www.rfc-editor.org/info/rfc7668>.
[RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability
Statement for the Routing Protocol for Low-Power and Lossy
Networks (RPL) in Advanced Metering Infrastructure (AMI)
Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017,
<http://www.rfc-editor.org/info/rfc8036>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-6lo-dect-ule] [I-D.ietf-6lo-dect-ule]
Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D.
Barthel, "Transmission of IPv6 Packets over DECT Ultra Low Barthel, "Transmission of IPv6 Packets over DECT Ultra Low
Energy", draft-ietf-6lo-dect-ule-07 (work in progress), Energy", draft-ietf-6lo-dect-ule-07 (work in progress),
October 2016. October 2016.
[I-D.ietf-6lo-6lobac] [I-D.ietf-6lo-6lobac]
Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, Lynn, K., Martocci, J., Neilson, C., and S. Donaldson,
skipping to change at page 20, line 44 skipping to change at page 27, line 29
Choi, Y., Youn, J., and Y. Hong, "Transmission of IPv6 Choi, Y., Youn, J., and Y. Hong, "Transmission of IPv6
Packets over Near Field Communication", draft-ietf-6lo- Packets over Near Field Communication", draft-ietf-6lo-
nfc-05 (work in progress), October 2016. nfc-05 (work in progress), October 2016.
[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-05 (work in progress), draft-ietf-lwig-energy-efficient-05 (work in progress),
October 2016. October 2016.
[I-D.ietf-roll-applicability-ami] [I-D.ietf-roll-aodv-rpl]
Cam-Winget, N., Hui, J., and D. Popa, "Applicability Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S.
Statement for the Routing Protocol for Low Power and Lossy Anand, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy
Networks (RPL) in AMI Networks", draft-ietf-roll- Networks (LLNs)", draft-ietf-roll-aodv-rpl-00 (work in
applicability-ami-15 (work in progress), October 2016. progress), December 2016.
[I-D.ietf-6tisch-6top-sf0]
Dujovne, D., Grieco, L., Palattella, M., and N. Accettura,
"6TiSCH 6top Scheduling Function Zero (SF0)", draft-ietf-
6tisch-6top-sf0-02 (work in progress), October 2016.
[I-D.satish-6tisch-6top-sf1]
Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S.
Anand, "Scheduling Function One (SF1) for hop-by-hop
Scheduling in 6tisch Networks", draft-satish-6tisch-6top-
sf1-02 (work in progress), August 2016.
[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.
[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]
"IEEE Standard, IEEE Std. 1901-2010 - IEEE Standard for
Broadband over Power Line Networks: Medium Access Control
and Physical Layer Specifications", 2010,
<https://standards.ieee.org/findstds/
standard/1901-2010.html>.
[IEEE1901.1]
"IEEE Standard (work-in-progress), IEEE-SA Standards
Board", <http://sites.ieee.org/sagroups-1901-1/>.
[IEEE1901.2]
"IEEE Standard, IEEE Std. 1901.2-2013 - IEEE Standard for
Low-Frequency (less than 500 kHz) Narrowband Power Line
Communications for Smart Grid Applications", 2013,
<https://standards.ieee.org/findstds/
standard/1901.2-2013.html>.
Authors' Addresses Authors' Addresses
Yong-Geun Hong Yong-Geun Hong
ETRI ETRI
161 Gajeong-Dong Yuseung-Gu 161 Gajeong-Dong Yuseung-Gu
Daejeon 305-700 Daejeon 305-700
Korea Korea
Phone: +82 42 860 6557 Phone: +82 42 860 6557
Email: yghong@etri.re.kr Email: yghong@etri.re.kr
skipping to change at page 21, line 34 skipping to change at page 29, line 4
Phone: +82 42 860 6557 Phone: +82 42 860 6557
Email: yghong@etri.re.kr Email: yghong@etri.re.kr
Carles Gomez Carles Gomez
Universitat Politecnica de Catalunya/Fundacio i2cat Universitat Politecnica de Catalunya/Fundacio i2cat
C/Esteve Terradas, 7 C/Esteve Terradas, 7
Castelldefels 08860 Castelldefels 08860
Spain Spain
Email: carlesgo@entel.upc.edu Email: carlesgo@entel.upc.edu
Younghwan Choi Younghwan Choi
ETRI ETRI
218 Gajeongno, Yuseong 218 Gajeongno, Yuseong
Daejeon 305-700 Daejeon 305-700
Korea Korea
Phone: +82 42 860 1429 Phone: +82 42 860 1429
Email: yhc@etri.re.kr Email: yhc@etri.re.kr
Deoknyong Ko Deoknyong Ko
SKtelecom SKtelecom
9-1 Byundang-gu Sunae-dong, Seongnam-si 9-1 Byundang-gu Sunae-dong, Seongnam-si
Gyeonggi-do 13595 Gyeonggi-do 13595
Korea Korea
Phone: +82 10 3356 8052 Phone: +82 10 3356 8052
Email: engineer@sk.com Email: engineer@sk.com
Abdur Rashid Sangi
Huawei Technologies
No.156 Beiqing Rd. Haidian District
Beijing 100095
P.R. China
Email: rashid.sangi@huawei.com
Take Aanstoot
Modio AB
S:t Larsgatan 15, 582 24
Linkoping
Sweden
Email: take@modio.se
 End of changes. 62 change blocks. 
122 lines changed or deleted 459 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/