< draft-ietf-6lo-use-cases-01.txt   draft-ietf-6lo-use-cases-02.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: September 13, 2017 UPC/i2cat Expires: January 4, 2018 UPC/i2cat
Y-H. Choi Y-H. Choi
ETRI ETRI
D-Y. Ko D-Y. Ko
SKtelecom SKtelecom
AR. Sangi AR. Sangi
Huawei Technologies Individual Contributor
Take. Aanstoot T. Aanstoot
Modio AB Modio AB
March 12, 2017 S. Chakrabarti
July 3, 2017
IPv6 over Constrained Node Networks(6lo) Applicability & Use cases IPv6 over Constrained Node Networks (6lo) Applicability & Use cases
draft-ietf-6lo-use-cases-01 draft-ietf-6lo-use-cases-02
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 provides practical deployment examples. In
deployment scenarios of 6lo technologies with the consideration of
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, PLC (IEEE ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, PLC (IEEE 1901),
1901), and IEEE 802.15.4e(6tisch) are widely used at constrained node and IEEE 802.15.4e (6tisch) are used as examples. The document
networks for typical services. Based on these link layer targets an audience who like to understand and evaluate running end-
technologies, IPv6 over networks of resource-constrained nodes has to-end IPv6 over the constrained link layer networks connecting
various and practical use cases. To efficiently implement typical devices to each other or to each cloud.
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 January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 and possible candidates . . . . . 4
3.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4 3.1. ITU-T G.9959 (specified) . . . . . . . . . . . . . . . . 4
3.2. Bluetooth LE . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Bluetooth LE (specified) . . . . . . . . . . . . . . . . 4
3.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. DECT-ULE (specified) . . . . . . . . . . . . . . . . . . 5
3.4. MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. MS/TP (specified) . . . . . . . . . . . . . . . . . . . . 5
3.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5. NFC (specified) . . . . . . . . . . . . . . . . . . . . . 6
3.6. LTE MTC . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6. PLC (specified) . . . . . . . . . . . . . . . . . . . . . 6
3.7. PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.7. IEEE 802.15.4e (specified) . . . . . . . . . . . . . . . 7
3.8. IEEE 802.15.4e . . . . . . . . . . . . . . . . . . . . . 8 3.8. LTE MTC (example of a potential candidate) . . . . . . . 8
3.9. Comparison between 6lo Link layer technologies . . . . . 8
4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 9 4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 9
5. Design Space . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. jupitermesh in Smart Grid using 6lo in network layer . . 9
6. 6lo Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Wi-SUN usage of 6lo stacks . . . . . . . . . . . . . . . 11
6.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 11 5. Design Space and Guidelines for 6lo Deployment . . . . . . . 12
6.2. Use case of Bluetooth LE: Smartphone-Based Interaction 5.1. Design Space Dimensions for 6lo Deployment . . . . . . . 12
with Constrained Devices . . . . . . . . . . . . . . . . 13 5.2. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) . . . . 14
6.3. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 14 6. 6lo Use Case Examples . . . . . . . . . . . . . . . . . . . . 16
6.4. Use case of MS/TP: Management of District Heating . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.5. Use case of NFC: Alternative Secure Transfer . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.6. Use case of LTE MTC: Gateway for Wireless Backhaul 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
Network . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
6.8. Use case of IEEE 802.15.4e: Industrial Automation . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Other 6lo Use Case Examples . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 A.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 A.2. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.3. Use case of MS/TP: Management of District Heating . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 A.4. Use case of NFC: Alternative Secure Transfer . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 27 A.5. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 A.6. Use case of IEEE 802.15.4e: Industrial Automation . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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][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, an appropriate fragmentation below to support an MTU of 1280 bytes, therefore an appropriate
and reassembly adaptation layer must be provided at the layer below fragmentation and reassembly adaptation layer must be provided at the
IPv6. Also, the limited size of IEEE 802.15.4 frame and low energy layer below IPv6. Also, the limited size of IEEE 802.15.4 frame and
consumption requirements make the need for header compression. IETF low energy consumption requirements make the need for header
6lowpan (IPv6 over Low powerWPAN) working group published, an compression. The IETF 6LoPWAN (IPv6 over Low powerWPAN) working
adaptation layer for sending IPv6 packets over IEEE 802.15.4 group published an adaptation layer for sending IPv6 packets over
[RFC4944], compression format for IPv6 datagrams over IEEE IEEE 802.15.4 [RFC4944], a compression format for IPv6 datagrams over
802.15.4-based networks [RFC6282], and Neighbor Discovery IEEE 802.15.4-based networks [RFC6282], and Neighbor Discovery
Optimization for 6lowpan [RFC6775]. Optimization for 6LoPWAN [RFC6775].
As IoT (Internet of Things) services become more popular, various As IoT (Internet of Things) services become more popular, IPv6 over
link layer technologies such as Bluetooth Low Energy (Bluetooth LE), various link layer technologies such as Bluetooth Low Energy
ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications - (Bluetooth LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless
Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token
Field Communication (NFC), Power Line Communication (PLC), and LTE Passing (MS/TP), Near Field Communication (NFC), Power Line
Machine Type Communication are actively used. And the transmission Communication (PLC), and IEEE 802.15.4e (TSCH), have been defined at
of IPv6 packets over these link layer technologies is required. A [IETF_6lo] working group. IPv6 stacks for constrained node networks
number of IPv6-over-foo documents have been developed in the IETF 6lo use a variation of the 6LoWPAN stack applied to each particular link
(IPv6 over Networks of Resource-constrained Nodes) and 6tisch (IPv6 layer technology.
over the TSCH mode of IEEE 802.15.4e) working groups.
In the 6lowpan 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. In this document, various design space dimensions area networks. Hence, this 6lo applicability document aims to
such as deployment, network size, power source, connectivity, multi- provide guidance to an audience who is new to IPv6-over-lowpower
hop communication, traffic pattern, security level, mobility, and QoS networks concept and wants to assess if variance of 6LoWPAN stack
were analyzed. And it described a fundamental set of 6lowpan [6lo] can be applied to the constrained L2 network of their interest.
application scenarios and use cases: Industrial monitoring-Hospital This 6lo applicability document puts together various design space
storage rooms, Structural monitoring-Bridge safety monitoring, dimensions such as deployment, network size, power source,
Connected home-Home automation and Smart grid assistance, Healthcare- connectivity, multi-hop communication, traffic pattern, security
Healthcare at home by tele-assistance, Vehicle telematics-telematics, level, mobility, and QoS requirements etc. And it described a few
and Agricultural monitoring-Automated vineyard. set of 6LoPWAN application scenarios and practical deployment as
examples.
Even though the [RFC6568] describes some potential application
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
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
application scenarios and use cases were based on the IEEE 802.15.4
technologies. Due to various link layer technologies such as ITU-T
G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, LTE MTC, Power Line
Communication (PLC), and IEEE 802.15.4e(6tisch), potential
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 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. those of 6LoWPAN defined for IEEE 802.15.4.
o 6lo applicability and use cases SHOULD cover various IoT related o It SHOULD cover various IoT related wire/wireless link layer
wire/wireless link layer technologies providing practical technologies providing practical information of such technologies.
information of such technologies.
o 6lo applicability and use cases SHOULD describe characteristics o A general guideline on how the 6LoWPAN stack can be modified for a
and typical use cases of each link layer technology, and then 6lo given L2 technology.
use cases's applicability.
o Example use cases and practical deployment examples.
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 3. 6lo Link layer technologies and possible candidates
3.1. ITU-T G.9959 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). 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]. The ITU-T G.9959 can be used for smart home
applications.
3.2. Bluetooth LE 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 Devices such as mobile phones, notebooks, tablets and other handheld
computing devices which will include Bluetooth 4.1 chipsets will computing devices which will include Bluetooth 4.1 chipsets will
probably also have the low-energy variant of Bluetooth. Bluetooth LE probably also have the low-energy variant of Bluetooth. Bluetooth LE
will also be included in many different types of accessories that will also be 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]. on the Internet [RFC7668]. A typical usage of Bluetooth LE is
smartphone-based interaction with constrained devices.
3.3. DECT-ULE 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
allocated by use of FDMA/TDMA/TDD techniques. allocated by use of FDMA/TDMA/TDD techniques.
skipping to change at page 5, line 45 skipping to change at page 5, line 36
The DECT ULE device can switch to the ULE mode of operation, The DECT ULE device can switch to the ULE mode of operation,
utilizing the new ULE MAC layer features. The DECT ULE Data Link utilizing the new ULE MAC layer features. The DECT ULE Data Link
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 [RFC8105]. DECT-ULE can be used
for smart metering in a home.
3.4. MS/TP 3.4. MS/TP (specified)
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 aspects: a) MS/TP devices typically have a continuous least three aspects: a) MS/TP devices typically have a continuous
skipping to change at page 6, line 25 skipping to change at page 6, line 16
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, although not according to standards, in lower speeds,
normally 9600 bit/s, re-purposed telecom wiring is widely in use, normally 9600 bit/s, re-purposed telecom wiring is widely in use,
keeping deployment cost down. It can support a data rate of 115,200 keeping deployment cost down. It can support a data rate of 115,200
baud on segments up to 1000 meters in length, or segments up to 1200 baud on segments up to 1000 meters in length, or segments up to 1200
meters in length at lower baud rates. An MS/TP link requires only a meters in length at lower baud rates. An MS/TP link requires only a
UART, an RS-485 transceiver with a driver that can be disabled, and a UART, an RS-485 transceiver with a driver that can be disabled, and a
5ms resolution timer. These features make MS/TP a cost-effective and 5ms resolution timer. These features make MS/TP a cost-effective and
very reliable field bus for the most numerous and least expensive very reliable field bus for the most numerous and least expensive
devices in a building automation network [I-D.ietf-6lo-6lobac]. devices in a building automation network [RFC8163]. MS/TP can be
used for the management of district heating.
3.5. NFC 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
infrastructure and it enables a consumer to utilize one device across infrastructure and it enables a consumer to utilize one device across
different systems. different systems.
skipping to change at page 6, line 49 skipping to change at page 6, line 41
Extending the capability of contactless card technology, NFC also Extending the capability of contactless card technology, NFC also
enables devices to share information at a distance that is less than enables devices to share information at a distance that is less than
10 cm with a maximum communication speed of 424 kbps. Users can 10 cm with a maximum communication speed of 424 kbps. Users can
share business cards, make transactions, access information from a share business cards, make transactions, access information from a
smart poster or provide credentials for access control systems with a smart poster or provide credentials for access control systems with a
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]. sharing is also available [I-D.ietf-6lo-nfc]. NFC can be used for
secure transfer in healthcare services.
3.6. LTE MTC
LTE category defines the overall performance and capabilities of the
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.
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 1 and category 0 could be used for low rate IoT service,
these categories are called LTE MTC (Machine Type Communication)
[LTE_MTC].
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
and low cost.
The below figure shows the primary characteristics of LTE MTC.
+------------+---------------------+-------------------+
| Category | Max. Data Rate Down | Max. Data Rate Up |
+------------+---------------------+-------------------+
| Category 0 | 1.0 Mbit/s | 1.0 Mbit/s |
| | | |
| Category 1 | 10.3 Mbit/s | 5.2 Mbit/s |
+------------+---------------------+-------------------+
Table 1: Primary characteristics of LTE MTC
3.7. PLC 3.6. PLC (specified)
Unlike other dedicated communication infrastructure, the required Unlike other dedicated communication infrastructure, the required
medium (power conductor) is widely available indoors and outdoors. medium (power conductor) is widely available indoors and outdoors.
Moreover, wire d technologies are more susceptible to cause Moreover, wired technologies are more susceptible to cause
interference but are more rel iable than their wireless counterparts. interference but are more reliable than their wireless counterparts.
PLC is a data transmission techniq ue that utilizes power conductors PLC is a data transmission technique that utilizes power conductors
as medium. as medium.
The below figure 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 2: 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 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 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 supports operating either indoor or even an outdoor environment. It is applicable to typical
in Low Voltage (LV) or High Voltage (HV) segment of PLC domain. It IoT applications such as: Building Automation, Renewable Energy,
is applicable to typical IoT applications such as: Building Advanced Metering, Street Lighting, Electric Vehicle, Smart Grid etc.
Automation, Renewable Energy, Advanced Metering, Street Lighting, Moreover, IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer
Electric Vehicle, Smart Grid etc. Narrowband operates either on FSK and fully endorses the security scheme defined in 802.15.4.
(Frequency Shift Keying), S (Spread) FSK, BPSK (Binary Phase Shift [RFC8036]. A typical use case of PLC is smart grid.
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 3.7. IEEE 802.15.4e (specified)
The Timeslotted 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.
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 packet exchanges
between neighbor nodes are done on a different frequency. This means between neighbor nodes are done on a different frequency. This 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.
- 6TiSCH at IETF defines communications of TSCH network and it
uses 6LoWPAN stack [RFC7554].
IEEE 802.15.4e can be used for industrial automation.
3.8. LTE MTC (example of a potential candidate)
LTE category defines the overall performance and capabilities of the
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.
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 1 and category 0 could be used for low rate IoT service,
these categories are called LTE MTC (Machine Type Communication)
[LTE_MTC].
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
and low cost. LTE MTC can be used for a gateway of a wireless
bachhaul network.
3.9. Comparison between 6lo Link layer technologies
In above clauses, various 6lo Link layer technologies and a possible
candidate are described. The following table shows that dominant
paramters of each use case corresponding to the 6lo link layer
technology.
+-----------+--------+--------+--------+--------+--------+--------+--------+
| | Z-Wave | BLE |DECT-ULE| MS/TP | NFC | PLC | TSCH |
+-----------+--------+--------+--------+--------+--------+--------+--------+
| | Home |Interact| | | Health-| |Industr-|
| Usage | Auto- |w/ Smart| Meter |District| care | Smart |ial Aut-|
| | mation | Phone | Reading| Heating| Service| Grid | mation |
+-----------+--------+--------+--------+--------+--------+--------+--------+
| Topology | L2-mesh| Star | Star | Bus | P2P | Tree | |
| & | or | | | | | | Mesh |
| Subnet | L3-mesh| No mesh| No mesh| MS/TP | L2-mesh| No mesh| |
+-----------+--------+--------+--------+--------+--------+--------+--------+
| | | | | | | | |
| Mobility | No | Low | No | No |Moderate| No | No |
| Reqmt | | | | | | | |
+-----------+--------+--------+--------+--------+--------+--------+--------+
| | High + | | High + | High + | | igh + | High + |
| Security | Privacy| Parti- | Privacy| Authen.| High |Encrypt.| Privacy|
| Reqmt |required| ally |required|required| |required|required|
+-----------+--------+--------+--------+--------+--------+--------+--------+
| | | | | | | | |
| Buffering | Low | Low | Low | Low | Low | Low | Low |
| Reqmpt | | | | | | | |
+-----------+--------+--------+--------+--------+--------+--------+--------+
| Latency, | | | | | | | |
| QoS | High | Low | Low | High | High | Low | High |
| Reqmt | | | | | | | |
+-----------+--------+--------+--------+--------+--------+--------+--------+
| | | | | | | | |
| Data |Infrequ-|Infrequ-|Infrequ-|Frequent| Small |Infrequ-|Infrequ-|
| Rate | ent | ent | ent | | | ent | ent |
+-----------+--------+--------+--------+--------+--------+--------+--------+
| RFC # | | | | | | | |
| or | RFC7428| RFC7668| RFC8105| RFC8163| 6lo-nfc|hou-6lo-| RFC7554|
| Draft | | | | | | plc | |
+-----------+--------+--------+--------+--------+--------+--------+--------+
Table 2: Comparison between 6lo Link layer technologies
4. 6lo Deployment Scenarios 4. 6lo Deployment Scenarios
In this clause, we will describe some 6lo deployment scenarios such 4.1. jupitermesh in Smart Grid using 6lo in network layer
as Smart Grid activity in WiSun
[TBD] jupiterMesh is a multi-hop wireless mesh network specification
designed mainly for deployment in large geographical areas. Each
subnet in jupiterMesh is able to cover an entire neighborhood with
thousands of nodes consisting of IPv6-enabled routers and end-points
(e.g., hosts). Automated network joining and load balancing allows a
seamless deployment of a large number of subnets.
5. Design Space The main application domains targeted by jupiterMesh are smart grid
and smart cities. This includes, but is not limited to the following
applications:
o Automated meter reading
o Distribution Automation (DA)
o Demand-side management (DSM)
o Demand-side response (DSR)
o Power outage reporting
o Street light monitoring and control
o Transformer load management
o EV charging coordination
o Energy theft
o Parking space locator
jupiterMesh specification is based on the following technologies:
o The PHY layer is based on IEEE 802.15.4 SUN specification [IEEE
802.15.4-2015], supporting multiple operating modes for deployment
in different regulatory domains and deployment scenarios in terms
of density and bandwidth requirements. jupiterMesh supports bit
rates from 50 kbps to 800 kbps, frame size up to 2048 bytes, up to
11 different RF bands and 3 modulation types (i.e., FSK, OQPSK and
OFDM).
o The MAC layer is based on IEEE 802.15.4 TSCH specification [IEEE
802.15.4-2015]. With frequency hopping capability, TSCH MAC
supports scheduling of dedicated timeslot enabling bandwidth
management and QOS.
o The security layer consists of a certificate-based (i.e. X.509)
network access authentication using EAP-TLS, with IEEE
802.15.9-based KMP (Key Management Protocol) transport, and PANA
and link layer encryption using AES-128 CCM as specified in IEEE
802.15.4-2015 [IEEE 802.15.4-2015].
o Address assignment and network configuration are specified using
DHCPv6 [RFC3315]. Neighbor Discovery (ND) [RFC6775] and stateless
address auto-configuration (SLAAC) are not supported.
o The network layer consists of IPv6, ICPMv6 and 6lo/6LoPWAN header
compression [RFC6282]. Multicast is supported using MPL. Two
domains are supported, a delay sensitive MPL domain for low
latency applications (e.g. DSM, DSR) and a delay insensitive one
for less stringent applications (e.g. OTA file transfers).
o The routing layer uses RPL [RFC6550] in non-storing mode with the
MRHOF objective function based on the ETX metric.
4.2. Wi-SUN usage of 6lo stacks
Wireless Smart Ubiquitous Network (Wi-SUN) is a technology based on
the IEEE 802.15.4g standard. Wi-SUN networks support star and mesh
topologies, as well as hybrid star/mesh deployments, but are
typically laid out in a mesh topology where each node relays data for
the network to provide network connectivity. Wi-SUN networks are
deployed on both powered and battery-operated devices.
The main application domains targeted by Wi-SUN are smart utility and
smart city networks. This includes, but is not limited to the
following applications:
o Advanced Metering
o Infrastructure (AMI)
o Distribution Automation
o Home Energy Management
o Infrastructure Management
o Intelligent Transportation Systems
o Smart Street Lighting
o Agriculture
o Structural health (bridges, buildings etc)
o Monitoring and Asset Management
o Smart Thermostats, Air Conditioning and Heat Controls
o Energy Usage Information Displays
The Wi-SUN Alliance Field Area Network (FAN) covers primarily outdoor
networks, and its specification is oriented towards meeting the more
rigorous challenges of these environments. Examples include from
meter to outdoor access point/router for AMI and DR, or between
switches for DA. However, nothing in the profile restricts it to
outdoor use. It has the following features;
o Open standards based on IEEE802, IETF, TIA, ETSI
o Architecture is an IPv6 frequency hopping wireless mesh network
with enterprise level security
o Simple infrastructure which is low cost, low complexity
o Enhanced network robustness, reliability, and resilience to
interference, due to high redundancy and frequency hopping
o Enhaced scalability, long range, and energy friendliness
o Supports multiple global license-exempt sub GHz bands
o Multi-vendor interoperability
o Very low power modes in development permitting long term battery
operation of network nodes
In the Wi-SUN FAN specification, adaptation layer based on 6lo and
IPv6 network layer are described. So, IPv6 protocol suite including
TCP/UDP, 6lo Adaptation, Header Compression, DHCPv6 for IP address
management, Routing using RPL, ICMPv6, and Unicast/Multicast
forwarding is utilized.
5. Design Space and Guidelines 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 the RFC 6568, the following design space dimensions are rate). In [RFC6568], 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). However, in this document, the following design space
dimensions are considered:
The design space dimensions of 6lo are a little different from those
of the RFC 6568 due to the different characteristics of 6lo link
layer technologies. The following design space dimensions can be
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.
skipping to change at page 10, line 35 skipping to change at page 13, line 30
6lo nodes. 6lo nodes.
o Data rate: Originally, the link layer technologies of 6lo have low o Data rate: Originally, 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 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 Requirements: Some 6lo use case can involve transferring o Security and Privacy Requirements: Some 6lo use case can involve
some important and personal data between 6lo nodes. In this case, transferring some important and personal data between 6lo nodes.
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 is dependent on the 6lo use case. If the 6lo nodes can move
or moved around, it requires a mobility management mechanism. or moved around, it requires a mobility management mechanism.
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.
skipping to change at page 11, line 18 skipping to change at page 14, line 13
continuous data and periodic data transmission. continuous data and periodic data transmission.
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 [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.
6. 6lo Use Cases 5.2. Guidelines for adopting IPv6 stack (6lo/6LoWPAN)
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
smart home applications. Born as a proprietary technology, Z-Wave
was specifically designed for this particular use case. Recently,
the Z-Wave radio interface (physical and MAC layers) has been
standardized as the ITU-T G.9959 specification.
Example: Use of ITU-T G.9959 for Home Automation
Variety of home devices (e.g. light dimmers/switches, plugs,
thermostats, blinds/curtains and remote controls) are augmented with
ITU-T G.9959 interfaces. A user may turn on/off or may control home
appliances by pressing a wall switch or by pressing a button in a
remote control. Scenes may be programmed, so that after a given
event, the home devices adopt a specific configuration. Sensors may
also periodically send measurements of several parameters (e.g. gas
presence, light, temperature, humidity, etc.) which are collected at
a sink device, or may generate commands for actuators (e.g. a smoke
sensor may send an alarm message to a safety system).
The devices involved in the described scenario are nodes of a network
that follows the mesh topology, which is suitable for path diversity
to face indoor multipath propagation issues. The multihop paradigm
allows end-to-end connectivity when direct range communication is not
possible. Security support is required, specially for safety-related
communication. When a user interaction (e.g. a button press)
triggers a message that encapsulates a command, if the message is
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
user interaction will be perceived by the user as immediate as long
as the reaction takes place within 0.5 seconds [RFC5826].
Dominant parameters in home automation scenarios with ITU-T G.9959:
o Deployment/Bootstrapping: Pre-planned.
o Topology: Mesh topology.
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
protocol).
o Multi-link subnet, single subnet: Multi-link subnet.
o Data rate: Small data rate, infrequent transmissions.
o Buffering requirements: Low requirement. The following guideline targets candidates for new constrained L2
technologies that consider running modified 6LoWPAN stack. The
modification of 6LoWPAN stack should be based on the following:
o Security requirements: Data privacy and security must be provided. o Addressing Model: Addressing model determines whether the device
Encryption is required. is capable of forming IPv6 Link-local and global addresses and
what is the best way to derive the IPv6 addresses for the
constrained L2 devices. Whether the device is capable of forming
IPv6 Link-local and global addresses, L2-address-derived IPv6
addresses are specified in [RFC4944], but there exist implications
for privacy. For global usage, a unique IPv6 address must be
derived using an assigned prefix and a unique interface ID.
[RFC8065] provides such guidelines. For MAC derived IPv6 address,
please refer to [RFC8163] for IPv6 address mapping examples.
Broadcast and multicast support are dependent on the L2 networks.
Most lowpower L2 implementations map multicast to broadcast
networks. So care must be taken in the design when to use
broadcast and try to stick to unicast messaging whenever possible.
o Mobility: Most devices are static. A few devices (e.g. remote o MTU Considerations: The deployment SHOULD consider their need for
control) are portable. maximum transmission unit of a packet (MTU) over the link layer
and should consider if fragmentation and reassembly of packets are
needed at the 6LoWPAN layer. For example, if the link-layer
supports fragmentation and reassembly of packets, then 6LoWPAN
layer may skip supporting fragmentation/reassembly. In fact, for
most efficiency, choosing a low-power link-layer that can carry
unfragmented application packets would be optimum for packet
transmission if the deployment can afford it. Please refer to 6lo
RFCs [RFC7668], [RFC8163], [RFC8105] for example guidance.
o Time Synchronization: TBD. o Mesh or L3-Routing: 6LoWPAN specifications do provide mechanisms
to support for mesh routing at L2. [RFC6550] defines L3 routing
for low power lossy networks using directed graphs. 6LoWPAN is
routing protocol agnostic and other L2 or L3 routing protocols can
be run using a 6LoWPAN stack.
o Reliability and QoS: Moderate to high level of reliability o Address Assignment: 6LoWPAN requires that IPv6 Neighbor Discovery
support. Actions as a result of human-generated traffic should for low power networks [RFC6775] be used for autoconfiguration of
occur after less than 0.5 seconds. stateless IPv6 address assignment. Considering the energy
sensitive networks [RFC6775] makes optimization from classical
IPv6 ND [RFC4861] protocol. It is the responsibility of the
deployment to ensure unique global IPv6 addresses for the Internet
connectivity. For local-only connectivity IPv6 ULA may be used.
[RFC6775] specifies the 6LoWPAN border router(6LBR) which is
responsible for prefix assignment to the 6lo/6LoWPAN network. 6LBR
can be connected to the Internet or Enterprise network via its one
of the interfaces. Please refer to [RFC7668] and [RFC8105] for
examples of address assignment considerations. In addition,
privacy considerations [RFC8065] must be consulted for
applicability. In certain scenarios, the deployment may not
support autoconfiguration of IPv6 addressing due to regulatory and
business reasons and may choose to offer a separate address
assignment service.
o Traffic patterns: Periodic (sensor readings) and aperiodic (user- o Header Compression: IPv6 header compression [RFC6282] is a vital
triggered interaction). part of IPv6 over low power communication. Examples of header
compression for different link-layers specifications are found in
[RFC7668], [RFC8163], [RFC8105]. A generic header compression
technique is specified in [RFC7400].
o Security Bootstrapping: Required. o Security and Encryption: Though 6LoWPAN basic specifications do
not address security at network layer, the assumption is that L2
security must be present. In addition, application level security
is highly desirable. The working groups [ace] and [core] should
be consulted for application and transport level security. 6lo
working group is working on address authentication [6lo-ap-nd] and
secure bootstrapping is also being discussed at IETF. However,
there may be different levels of security available in a
deployment through other standards such as hardware level security
or certificates for initial booting process. Encryption is quite
important if the implementation can afford it.
o Power use strategy: Mix of P1 (Low-power) devices and P9 (Always- o Additional processing: [RFC8066] defines guidelines for ESC
on) devices. dispatch octets use in the 6LoWPAN header. An implementation may
take advantage of ESC header to offer a deployment specific
processing of 6LoWPAN packets.
o Update firmware requirements: TBD. 6. 6lo Use Case Examples
6.2. Use case of Bluetooth LE: Smartphone-Based Interaction with As IPv6 stacks for constrained node networks use a variation of the
Constrained Devices 6LoWPAN stack applied to each particular link layer technology,
various 6lo use cases can be provided. In this clause, one 6lo use
case example of Bluetooth LE (Smartphone-Based Interaction with
Constrained Devices) is described. Other 6lo use case examples are
described in Appendix.
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,
skipping to change at page 13, line 39 skipping to change at page 16, line 45
(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.
Dominant parameters in fitness scenarios with Bluetooth LE: 7. IANA Considerations
o Deployment/Bootstrapping: Pre-planned. There are no IANA considerations related to this document.
o Topology: Star topology. 8. Security Considerations
o L2-mesh or L3-mesh: No. Security considerations are not directly applicable to this document.
The use cases will use the security requirements described in the
protocol specifications.
o Multi-link subnet, single subnet: Multi-link subnet. 9. Acknowledgements
o Data rate: TBD. Carles Gomez has been funded in part by the Spanish Government
(Ministerio de Educacion, Cultura y Deporte) through the Jose
Castillejo grant CAS15/00336. His contribution to this work has been
carried out in part during his stay as a visiting scholar at the
Computer Laboratory of the University of Cambridge.
o Buffering requirements: Low requirement. Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault,
and Jianqiang HOU have provided valuable feedback for this draft.
o Security requirements: For health-critical information, data Das Subir and Michel Veillette have provided valuable information of
privacy and security must be provided. Encryption is required. jupiterMesh and Paul Duffy has provided valuable information of Wi-
Some types of notifications sent by the smartphone may not need. SUN for this draft.
o Mobility: Low. 10. References
o Time Synchronization: the link layer, which is based on TDMA, 10.1. Normative References
provides a basis for time synchronization.
o Reliability and QoS: a relatively low ratio of message losses is [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
acceptable for periodic sensor readings. End-to-end latency of Requirement Levels", BCP 14, RFC 2119,
sensor readings should be low for critical notifications or DOI 10.17487/RFC2119, March 1997,
alarms, generated by either the smartphone or an Internet cloud <http://www.rfc-editor.org/info/rfc2119>.
service.
o Traffic patterns: periodic (sensor readings) and aperiodic [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
(smartphone-generated notifications). over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007,
<http://www.rfc-editor.org/info/rfc4919>.
o Security Bootstrapping: Required. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
o Power use strategy: P1 (Low-power) devices. [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, DOI 10.17487/RFC5826, April 2010,
<http://www.rfc-editor.org/info/rfc5826>.
o Update firmware requirements: TBD. [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
6.3. Use case of DECT-ULE: Smart Home [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and
Application Spaces for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)", RFC 6568,
DOI 10.17487/RFC6568, April 2012,
<http://www.rfc-editor.org/info/rfc6568>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
2014, <http://www.rfc-editor.org/info/rfc7400>.
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
over ITU-T G.9959 Networks", RFC 7428,
DOI 10.17487/RFC7428, February 2015,
<http://www.rfc-editor.org/info/rfc7428>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015,
<http://www.rfc-editor.org/info/rfc7554>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<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>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <http://www.rfc-editor.org/info/rfc8065>.
[RFC8066] Chakrabarti, S., Montenegro, G., Droms, R., and J.
Woodyatt, "IPv6 over Low-Power Wireless Personal Area
Network (6LoWPAN) ESC Dispatch Code Points and
Guidelines", RFC 8066, DOI 10.17487/RFC8066, February
2017, <http://www.rfc-editor.org/info/rfc8066>.
[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,
M., and D. Barthel, "Transmission of IPv6 Packets over
Digital Enhanced Cordless Telecommunications (DECT) Ultra
Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
2017, <http://www.rfc-editor.org/info/rfc8105>.
[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S.
Donaldson, "Transmission of IPv6 over Master-Slave/Token-
Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
May 2017, <http://www.rfc-editor.org/info/rfc8163>.
10.2. Informative References
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[I-D.ietf-6lo-nfc]
Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi,
"Transmission of IPv6 Packets over Near Field
Communication", draft-ietf-6lo-nfc-07 (work in progress),
June 2017.
[I-D.ietf-lwig-energy-efficient]
Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy-
Efficient Features of Internet of Things Protocols",
draft-ietf-lwig-energy-efficient-07 (work in progress),
March 2017.
[I-D.ietf-roll-aodv-rpl]
Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S.
Anand, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy
Networks (LLNs)", draft-ietf-roll-aodv-rpl-01 (work in
progress), March 2017.
[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-04 (work in progress), April 2017.
[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-03 (work in progress), February 2017.
[IETF_6lo]
"IETF IPv6 over Networks of Resource-constrained Nodes
(6lo) working group",
<https://datatracker.ietf.org/wg/6lo/charter/>.
[G.9959] "International Telecommunication Union, "Short range
narrow-band digital radiocommunication transceivers - PHY
and MAC layer specifications", ITU-T Recommendation",
January 2015.
[LTE_MTC] "3GPP TS 36.306 V13.0.0, 3rd Generation Partnership
Project; Technical Specification Group Radio Access
Network; Evolved Universal Terrestrial Radio Access
(E-UTRA); User Equipment (UE) radio access capabilities
(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>.
Appendix A. Other 6lo Use Case Examples
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
smart home applications. Born as a proprietary technology, Z-Wave
was specifically designed for this particular use case. Recently,
the Z-Wave radio interface (physical and MAC layers) has been
standardized as the ITU-T G.9959 specification.
Example: Use of ITU-T G.9959 for Home Automation
Variety of home devices (e.g. light dimmers/switches, plugs,
thermostats, blinds/curtains and remote controls) are augmented with
ITU-T G.9959 interfaces. A user may turn on/off or may control home
appliances by pressing a wall switch or by pressing a button in a
remote control. Scenes may be programmed, so that after a given
event, the home devices adopt a specific configuration. Sensors may
also periodically send measurements of several parameters (e.g. gas
presence, light, temperature, humidity, etc.) which are collected at
a sink device, or may generate commands for actuators (e.g. a smoke
sensor may send an alarm message to a safety system).
The devices involved in the described scenario are nodes of a network
that follows the mesh topology, which is suitable for path diversity
to face indoor multipath propagation issues. The multihop paradigm
allows end-to-end connectivity when direct range communication is not
possible. Security support is required, specially for safety-related
communication. When a user interaction (e.g. a button press)
triggers a message that encapsulates a command, if the message is
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
user interaction will be perceived by the user as immediate as long
as the reaction takes place within 0.5 seconds [RFC5826].
A.2. Use case of DECT-ULE: Smart Home
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.
skipping to change at page 15, line 5 skipping to change at page 22, line 33
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.
Dominant parameters in smart metering scenarios with DECT-ULE: A.3. Use case of MS/TP: Management of District Heating
o Deployment/Bootstrapping: Pre-planned.
o Topology: Star topology.
o L2-mesh or L3-mesh: No.
o Multi-link subnet, single subnet: Multi-link 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: No.
o Time Synchronization: TBD.
o Reliability and QoS: bounded latency, stringent reliability
service agreements [RFC8036].
o Traffic patterns: Periodic (meter reading notifications sent by
the meter) and aperiodic (user- or company-triggered queries to
the meter, and messages triggered by local events such as power
outage or leak detection [RFC8036].
o Security Bootstrapping: required.
o Power use strategy: P0 (Normally-off) for devices with long sleep
intervals (i.e. greater than ~10 seconds) which then may need to
resynchronize again, and P1 (Low-power) for short sleep intervals.
P9 (Always-on) for the Fixed Part (FP), which is the central node
in the star topology.
o Update firmware requirements: TBD.
6.4. Use case of MS/TP: Management of District Heating
The key feature of MS/TP is it's ability to run on the same cabling 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 as BACnet and some use of ModBus, the defacto standard for low
bandwith industry communication. Specially Modbus has been around bandwith industry communication. Specially Modbus has been around
since the 1980 and is still the standard for talking to fans, heat since the 1980 and is still the standard for talking to fans, heat
pumps, water purifying equipment and everything else delivering pumps, water purifying equipment and everything else delivering
electricity, clean water and ventilation. electricity, clean water and ventilation.
Example: Use of MS/TP for management of district heating Example: Use of MS/TP for management of district heating
skipping to change at page 16, line 26 skipping to change at page 23, line 15
fans have a correct speed and are switched off in case district fans have a correct speed and are switched off in case district
heating fails to prevent cooling out the building and give certain heating fails to prevent cooling out the building and give certain
commands in case smoke is detected. Speed is not important, in this commands in case smoke is detected. Speed is not important, in this
usecase, 19,200 bit/s capable equipment is sold as high speed usecase, 19,200 bit/s capable equipment is sold as high speed
communication capable. Reliability is important, this not working communication capable. Reliability is important, this not working
will easily give millions of dollars of damage. Normally the setup will easily give millions of dollars of damage. Normally the setup
is that the SCADA device asks a question to a specific controlling is that the SCADA device asks a question to a specific controlling
device, gets an answer from the controlling device, asks a new device, gets an answer from the controlling device, asks a new
question to some other device. question to some other device.
o Deployment/Bootstrapping: Pre-planned. A.4. Use case of NFC: Alternative Secure Transfer
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
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.
serious issues should be transferred securely, but data transfer by
using Wi-Fi and Bluetooth connections cannot always be secure because
of their a little long radio frequency range. Hackers can overhear
the personal data transfer behind hidden areas. Therefore, methods
need to be alternatively selected to transfer secured data. Voice
and video data, which are not respectively secure and requires long
transmission range, can be transferred by 3G/4G technologies, such as
WCDMA, GSM, and LTE. Big size data, which are not secure and
requires high speed and broad bandwidth, can be transferred by Wi-Fi
and wired network technologies. However, the personal data, which
pose serious issues if mishandled while transferred in wireless
domain, can be securely transferred by NFC technology. It has very
short frequency range - nearly single touch communication.
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
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
skipping to change at page 18, line 5 skipping to change at page 23, line 41
be very time-critical. In addition, privacy also becomes a serious be very time-critical. In addition, privacy also becomes a serious
issue in this case, as the sensed data is very personal. issue in this case, as the sensed data is very personal.
While the senior citizen is provided audio and video healthcare While the senior citizen is provided audio and video healthcare
services by a tele-assistance based on LTE connections, the senior services by a tele-assistance based on LTE connections, the senior
citizen can alternatively use NFC connections to transfer the citizen can alternatively use NFC connections to transfer the
personal sensed data to the tele-assistance. At this moment, hidden personal sensed data to the tele-assistance. At this moment, hidden
hackers can overhear the data based on the LTE connection, but they hackers can overhear the data based on the LTE connection, but they
cannot gather the personal data over the NFC connection. cannot gather the personal data over the NFC connection.
+-------------+ +-------------+ A.5. Use case of PLC: Smart Grid
|voice & video|....... LTE connection ......>|voice & video|
| data |<...... LTE connection .......| data |
+-------------+ +-------------+
| sensed data |....... NFC connection ......>| |
| |<...... NFC connection .......| personal |
| | | result data |
+-------------+ +-------------+
(patient) (tele-assistance)
Figure 1: Alternative Secure Transfer in Healthcare Services
Dominant parameters in secure transfer by using NFC in healthcare
services:
o Deployment/Bootstrapping: Pre-planned. MP2P/P2MP (data
collection), P2P (local diagnostic).
o Topology: Small, NFC-enabled device connected to the Internet.
o L2-mesh or L3-mesh: NFC does not support L2-mesh, L3-mesh can be
configured.
o Multi-link subnet, single subnet: a single hop for gateway;
patient's body network is mesh topology.
o Data rate: Small data rate.
o Buffering requirements: Low requirement.
o Security requirements: Data privacy and security must be provided.
Encryption is required.
o Mobility: Moderate (patient's mobility).
o Time Synchronization: Highly required.
o Reliability and QoS: High level of reliability support (life-or-
death implication), role-based.
o Traffic patterns: Short data length and periodic (randomly).
o Security Bootstrapping: Highly required.
o Other Issues: Plug-and-play configuration is required for mainly
non-technical end-users. Real-time data acquisition and analysis
are important. Efficient data management is needed for various
devices that have different duty cycles, and for role-based data
control. Reliability and robustness of the network are also
essential.
o Power use strategy: TBD.
o Update firmware requirements: TBD.
6.6. Use case of LTE MTC: Gateway for Wireless Backhaul Network
Wireless link layer technologies can be divided into short range
connectivity and long range connectivity. BLE, ITU-T G.9959
(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
long range connectivity technology. It is LPWAN (Low Power Wide Area
Network) technology such as LoRa, Sigfox, Wi-Sun etc. Therefore, the
use case of LTE MTC could be used in LPWAN.
Example: Use of LTE MTC for LoRa gateway
LoRa is one of the most promising technology of LPWAN. LoRa network
architecture has a star of star topology. LoRa gateway relay the
messages from LoRa end device to application server and vice versa.
LoRa gateway can have two types of backhaul, wired and wireless
backhaul.
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
above LTE category 2, it is helpful to design to use LTE MTC.
Moreover, the maximum date rate of LoRa end device is 50kbps, it is
sufficient to use LTE MTC without using category 2.
Dominant parameters in LoRa gateway scenarios in above example:
o Deployment/Bootstrapping: Pre-planned.
o Topology: Star topology.
o L2-mesh or L3-mesh: No.
o Multi-link subnet, single subnet: Single subnet.
o Data rate: Depends on 3GPP specification.
o Buffering requirements: High requirement.
o Security requirements: No, because data security is already
provided in LoRa specification.
o Mobility: Static.
o Time Synchronization: Highly required.
o Reliability and QoS: TBD.
o Traffic patterns: Random.
o Security Bootstrapping: Required.
o Power use strategy: P9 (Always-on).
o Update firmware requirements: TBD.
Example: Use of LTE MTC for controlling car
Car sharing services are becoming more popular. Customers wish to
control the car with smart phone application. For example, customers
wish to lock/unlock the car door with smart phone application,
because customers may not have a car key. Customers wish to blow
with smart phone application to locate the car easily.
Therefore, rental car should have a long range connectivity capable
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
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
instead of category 2.
Dominant parameters in controlling car scenarios in above example:
o Deployment/Bootstrapping: Pre-planned.
o Topology: Star topology.
o L2-mesh or L3-mesh: No.
o Multi-link subnet, single subnet: Single subnet.
o Data rate: Depends on 3GPP specification.
o Buffering requirements: High requirement.
o Security requirements: High requirement.
o Mobility: Always dynamic .
o Time Synchronization: Highly required.
o Reliability and QoS: TBD.
o Traffic patterns: Random.
o Security Bootstrapping: Required.
o Power use strategy: P1 (Low-power).
6.7. Use case of PLC: Smart Grid
Smart grid concept is based on numerous operational and energy Smart grid concept is based on numerous operational and energy
measuring sub-systems of an electric grid. It comprises of multiple measuring sub-systems of an electric grid. It comprises of multiple
administrative levels/segments to provide connectivity among these administrative levels/segments to provide connectivity among these
numerous components. Last mile connectivity is established over LV numerous components. Last mile connectivity is established over LV
segment, whereas connectivity over electricity distribution takes segment, whereas connectivity over electricity distribution takes
place in HV segment. place in HV segment.
Although other wired and wireless technologies are also used in Smart Although other wired and wireless technologies are also used in Smart
Grid (Advance Metering Infrastructure - AMI, Demand Response - DR, Grid (Advance Metering Infrastructure - AMI, Demand Response - DR,
skipping to change at page 21, line 52 skipping to change at page 24, line 32
actions like notification of electricity charges according to the actions like notification of electricity charges according to the
commands from the utility company. commands from the utility company.
With the existing power line infrastructure as communication medium, With the existing power line infrastructure as communication medium,
cost on building up the PLC network is naturally saved, and more cost on building up the PLC network is naturally saved, and more
importantly, labor operational costs can be minimized from a long- importantly, labor operational costs can be minimized from a long-
term perspective. Furthermore, this AMI application speeds up term perspective. Furthermore, this AMI application speeds up
electricity charge, reduces losses by restraining power theft and electricity charge, reduces losses by restraining power theft and
helps to manage the health of the grid based on line loss analysis. 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 Example: Use of PLC (IEEE1901.1) for WASA in Smart Grid
Many sub-systems of Smart Grid require low data rate and narrowband Many sub-systems of Smart Grid require low data rate and narrowband
variant (IEEE1901.2) of PLC fulfils such requirements. Recently, variant (IEEE1901.2) of PLC fulfils such requirements. Recently,
more complex scenarios are emerging that require higher data rates. 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 WASA sub-system is an appropriate example that collects large amount
of information about the current state of the grid over wide area of information about the current state of the grid over wide area
from electric substations as well as power transmission lines. The from electric substations as well as power transmission lines. The
collected feedback is used for monitoring, controlling and protecting collected feedback is used for monitoring, controlling and protecting
all the sub-systems. all the sub-systems.
Dominant parameters in WASA scenario with above example: A.6. Use case of IEEE 802.15.4e: Industrial Automation
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 Typical scenario of Industrial Automation where sensor and actuators
are connected through the time-slotted radio access (IEEE 802.15.4e). 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 For that, there will be a point-to-point control signal exchange in
between sensors and actuators to trigger the critical control between sensors and actuators to trigger the critical control
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
skipping to change at page 24, line 34 skipping to change at page 25, line 24
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.
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
There are no IANA considerations related to this document.
8. Security Considerations
[TBD]
9. Acknowledgements
Carles Gomez has been funded in part by the Spanish Government
(Ministerio de Educacion, Cultura y Deporte) through the Jose
Castillejo grant CAS15/00336. His contribution to this work has been
carried out in part during his stay as a visiting scholar at the
Computer Laboratory of the University of Cambridge.
Samita Chakrabarti, Thomas Watteyne, Pascal Thubert, Xavier
Vilajosana, Daniel Migault, and Jianqiang HOU have provided valuable
feedback for this draft.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007,
<http://www.rfc-editor.org/info/rfc4919>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, DOI 10.17487/RFC5826, April 2010,
<http://www.rfc-editor.org/info/rfc5826>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
[RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and
Application Spaces for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)", RFC 6568,
DOI 10.17487/RFC6568, April 2012,
<http://www.rfc-editor.org/info/rfc6568>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
over ITU-T G.9959 Networks", RFC 7428,
DOI 10.17487/RFC7428, February 2015,
<http://www.rfc-editor.org/info/rfc7428>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<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
[I-D.ietf-6lo-dect-ule]
Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D.
Barthel, "Transmission of IPv6 Packets over DECT Ultra Low
Energy", draft-ietf-6lo-dect-ule-07 (work in progress),
October 2016.
[I-D.ietf-6lo-6lobac]
Lynn, K., Martocci, J., Neilson, C., and S. Donaldson,
"Transmission of IPv6 over MS/TP Networks", draft-ietf-
6lo-6lobac-05 (work in progress), June 2016.
[I-D.ietf-6lo-nfc]
Choi, Y., Youn, J., and Y. Hong, "Transmission of IPv6
Packets over Near Field Communication", draft-ietf-6lo-
nfc-05 (work in progress), October 2016.
[I-D.ietf-lwig-energy-efficient]
Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy-
Efficient Features of Internet of Things Protocols",
draft-ietf-lwig-energy-efficient-05 (work in progress),
October 2016.
[I-D.ietf-roll-aodv-rpl]
Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S.
Anand, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy
Networks (LLNs)", draft-ietf-roll-aodv-rpl-00 (work in
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
narrow-band digital radiocommunication transceivers - PHY
and MAC layer specifications", ITU-T Recommendation",
January 2015.
[LTE_MTC] "3GPP TS 36.306 V13.0.0, 3rd Generation Partnership
Project; Technical Specification Group Radio Access
Network; Evolved Universal Terrestrial Radio Access
(E-UTRA); User Equipment (UE) radio access capabilities
(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 29, line 23 skipping to change at page 26, line 23
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 Abdur Rashid Sangi
Huawei Technologies Individual Contributor
No.156 Beiqing Rd. Haidian District
Beijing 100095
P.R. China
Email: rashid.sangi@huawei.com Email: sangi_bahrian@yahoo.com
Take Aanstoot Take Aanstoot
Modio AB Modio AB
S:t Larsgatan 15, 582 24 S:t Larsgatan 15, 582 24
Linkoping Linkoping
Sweden Sweden
Email: take@modio.se Email: take@modio.se
Samita Chakrabarti
San Jose, CA
USA
Email: samitac.ietf@gmail.com
 End of changes. 83 change blocks. 
779 lines changed or deleted 630 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/