6Lo Working Group Y-G. Hong
Internet-Draft ETRI
Intended status: Standards Track C. Gomez
Expires: May 3, 2017 UPC/i2cat
Y-H. Choi
ETRI
D-Y. Ko
SKtelecom
October 30, 2016
IPv6 over Constrained Node Networks(6lo) Applicability & Use cases
draft-hong-6lo-use-cases-03
Abstract
This document describes the applicability of IPv6 over constrained
node networks (6lo) and use cases. It describes the practical
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
ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, LTE MTC, and IEEE
802.15.4e(6tisch) are widely used at constrained node networks for
typical services. Based on these link layer technologies, IPv6 over
networks of resource-constrained nodes has various and practical use
cases. To efficiently implement typical services, the applicability
and consideration of several design space dimensions are described.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2017.
Hong, et al. Expires May 3, 2017 [Page 1]
Internet-Draft 6lo Applicability & Use cases October 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. 6lo Link layer technologies . . . . . . . . . . . . . . . . . 4
3.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . 4
3.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Master-Slave/Token-Passing . . . . . . . . . . . . . . . 5
3.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6. LTE MTC . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.7. IEEE 802.15.4e . . . . . . . . . . . . . . . . . . . . . 7
4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 8
5. Design Space . . . . . . . . . . . . . . . . . . . . . . . . 8
6. 6lo Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 10
6.2. Use case of Bluetooth Low Energy: Smartphone-Based
Interaction with Constrained Devices . . . . . . . . . . 11
6.3. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 13
6.4. Use case of MS/TP: . . . . . . . . . . . . . . . . . . . 14
6.5. Use case of NFC: Alternative Secure Transfer . . . . . . 14
6.6. Use case of LTE MTC . . . . . . . . . . . . . . . . . . . 16
6.7. Use case of IEEE 802.15.4e: . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Hong, et al. Expires May 3, 2017 [Page 2]
Internet-Draft 6lo Applicability & Use cases October 2016
1. Introduction
Running IPv6 on constrained node networks has different features from
general node networks due to the characteristics of constrained node
networks such as small packet size, short link-layer address, low
bandwidth, network topology, low power, low cost, and large number of
devices [RFC4919]. For example, because some IEEE 802.15.4 link
layers have a frame size of 127 octets and IPv6 requires the layer
below to support an MTU of 1280 bytes, an appropriate fragmentation
and reassembly adaptation layer must be provided at the layer of
below IPv6. Also, the limited size of IEEE 802.15.4 frame and low
energy consumption requirements make the need for header compression.
IETF 6lowpan (IPv6 over Low powerWPAN) working group published, an
adaptation layer for sending IPv6 packets over IEEE 802.15.4
[RFC4944], compression format for IPv6 datagrams over IEEE
802.15.4-based networks [RFC6282], and Neighbor Discovery
Optimization for 6lowpan [RFC6775].
As IoT (Internet of Things) services become more popular, various
link layer technologies such as Bluetooth Low Energy (Bluetooth LE),
ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications -
Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near
Field Communication (NFC), and LTE Machine Type Communication are
actively used. And the transmission of IPv6 packets over these link
layer technologies is required. A number of IPv6-over-foo documents
have been developed in the IETF 6lo (IPv6 over Networks of Resource-
constrained Nodes) and 6tisch (IPv6 over the TSCH mode of IEEE
802.15.4e) working groups.
In the 6lowpan working group, the [RFC6568], "Design and Application
Spaces for 6LoWPANs" was published and it describes potential
application scenarios and use cases for low-power wireless personal
area networks. In this document, various design space dimensions
such as deployment, network size, power source, connectivity, multi-
hop communication, traffic pattern, security level, mobility, and QoS
were analyzed. And it described a fundamental set of 6lowpan
application scenarios and use cases: Industrial monitoring-Hospital
storage rooms, Structural monitoring-Bridge safety monitoring,
Connected home-Home Automation, Healthcare-Healthcare at home by
tele-assistance, Vehicle telematics-telematics, and Agricultural
monitoring-Automated vineyard.
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
Hong, et al. Expires May 3, 2017 [Page 3]
Internet-Draft 6lo Applicability & Use cases October 2016
technologies. Due to various link layer technologies such as ITU-T
G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, LTE MTC, and IEEE
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,
considering the following:
o 6lo applicability and use cases MAY be uniquely different from
those of 6lowpan.
o 6lo applicability and use cases SHOULD cover various IoT related
wire/wireless link layer technologies providing practical
information of such technologies.
o 6lo applicability and use cases SHOULD describe characteristics
and typical use cases of each link layer technology, and then 6lo
use cases's applicability.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. 6lo Link layer technologies
3.1. ITU-T G.9959
The ITU-T G.9959 recommendation [G.9959] targets low-power Personal
Area Networks (PANs). G.9959 defines how a unique 32-bit HomeID
network identifier is assigned by a network controller and how an
8-bit NodeID host identifier is allocated to each node. NodeIDs are
unique within the network identified by the HomeID. The G.9959
HomeID represents an IPv6 subnet that is identified by one or more
IPv6 prefixes [RFC7428].
3.2. Bluetooth Low Energy
Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth
4.1, and developed even further in successive versions. Bluetooth
SIG has also published Internet Protocol Support Profile (IPSP). The
IPSP enables discovery of IP-enabled devices and establishment of
link-layer connection for transporting IPv6 packets. IPv6 over
Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or
newer.
Hong, et al. Expires May 3, 2017 [Page 4]
Internet-Draft 6lo Applicability & Use cases October 2016
Devices such as mobile phones, notebooks, tablets and other handheld
computing devices which will include Bluetooth 4.1 chipsets will
probably also have the low-energy variant of Bluetooth. Bluetooth LE
will also be included in many different types of accessories that
collaborate with mobile devices such as phones, tablets and notebook
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
on the Internet [RFC7668].
3.3. DECT-ULE
DECT ULE is a low power air interface technology that is designed to
support both circuit switched services, such as voice communication,
and packet mode data services at modest data rate.
The DECT ULE protocol stack consists of the PHY layer operating at
frequencies in the 1880 - 1920 MHz frequency band depending on the
region and uses a symbol rate of 1.152 Mbps. Radio bearers are
allocated by use of FDMA/TDMA/TDD techniques.
In its generic network topology, DECT is defined as a cellular
network technology. However, the most common configuration is a star
network with a single Fixed Part (FP) defining the network with a
number of Portable Parts (PP) attached. The MAC layer supports
traditional DECT as this is used for services like discovery,
pairing, security features etc. All these features have been reused
from DECT.
The DECT ULE device can switch to the ULE mode of operation,
utilizing the new ULE MAC layer features. The DECT ULE Data Link
Control (DLC) provides multiplexing as well as segmentation and re-
assembly for larger packets from layers above. The DECT ULE layer
also implements per-message authentication and encryption. The DLC
layer ensures packet integrity and preserves packet order, but
delivery is based on best effort.
The current DECT ULE MAC layer standard supports low bandwidth data
broadcast. However the usage of this broadcast service has not yet
been standardized for higher layers [I-D.ietf-6lo-dect-ule].
3.4. Master-Slave/Token-Passing
MS/TP is a contention-free access method for the RS-485 physical
layer, which is used extensively in building automation networks.
An MS/TP device is typically based on a low-cost microcontroller with
limited processing power and memory. Together with low data rates
and a small address space, these constraints are similar to those
Hong, et al. Expires May 3, 2017 [Page 5]
Internet-Draft 6lo Applicability & Use cases October 2016
faced in 6LoWPAN networks and suggest some elements of that solution
might be leveraged. MS/TP differs significantly from 6LoWPAN in at
least three respects: a) MS/TP devices typically have a continuous
source of power, b) all MS/TP devices on a segment can communicate
directly so there are no hidden node or mesh routing issues, and c)
recent changes to MS/TP provide support for large payloads,
eliminating the need for link-layer fragmentation and reassembly.
MS/TP is designed to enable multidrop networks over shielded twisted
pair wiring. It can support a data rate of 115,200 baud on segments
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 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 field bus for the
most numerous and least expensive devices in a building automation
network [I-D.ietf-6lo-6lobac].
3.5. NFC
NFC technology enables simple and safe two-way interactions between
electronic devices, allowing consumers to perform contactless
transactions, access digital content, and connect electronic devices
with a single touch. NFC complements many popular consumer level
wireless technologies, by utilizing the key elements in existing
standards for contactless card technology (ISO/IEC 14443 A&B and
JIS-X 6319-4). NFC can be compatible with existing contactless card
infrastructure and it enables a consumer to utilize one device across
different systems.
Extending the capability of contactless card technology, NFC also
enables devices to share information at a distance that is less than
10 cm with a maximum communication speed of 424 kbps. Users can
share business cards, make transactions, access information from a
smart poster or provide credentials for access control systems with a
simple touch.
NFC's bidirectional communication ability is ideal for establishing
connections with other technologies by the simplicity of touch. In
addition to the easy connection and quick transactions, simple data
sharing is also available [I-D.ietf-6lo-nfc].
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
Hong, et al. Expires May 3, 2017 [Page 6]
Internet-Draft 6lo Applicability & Use cases October 2016
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 have the advantages compared to above category 2 to be used
for low rate IoT service such as low power and low cost.
The below figure shows the primary characteristics of LTE MTC.
+------------+---------------------+-------------------+
| Category | Max. Date Rate Down | Max. Date 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. IEEE 802.15.4e
The Timeslotted Channel Hopping (TSCH) mode was introduced in the
IEEE 802.15.4-2015 standard. In a TSCH network, all nodes are
synchronized. Time is sliced up into timeslots. The duration of a
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
acknowledgment to indicate successful reception. Timeslots are
grouped into one of more slotframes, which repeat over time.
All the communication in the network is orchestrated by a
communication schedule which indicates to each node what to do in
each of the timeslots of a slotframe: transmit, listen or sleep. The
communication schedule can be built so that the right amount of link-
layer resources (the cells in the schedule) are scheduled to satisfy
the communication needs of the applications running on the network,
while keeping the energy consumption of the nodes very low. Cells
can be scheduled in a collision-free way, introducing a high level of
determinism to the network.
A TSCH network exploits channel hopping: subsequent packets exchanged
between neighbor nodes are done so on a different frequency. This
means that, if a frame isn't received, the transmitter node will re-
transmitt the frame on a different frequency. The resulting "channel
hopping" efficiently combats external interference and multi-path
fading.
The main benefits of IEEE 802.15.4 TSCH are:
Hong, et al. Expires May 3, 2017 [Page 7]
Internet-Draft 6lo Applicability & Use cases October 2016
- ultra high reliability. Off-the-shelf commercial products offer
over 99.999% end-to-end reliability.
- ultra low-power consumption. Off-the-shelf commercial products
offer over a decade of battery lifetime.
4. 6lo Deployment Scenarios
In this clause, we will describe some 6lo deployment scenrios such as
Smart Grid activity in WiSun
[TBD]
5. Design Space
The [RFC6568] lists the dimensions used to describe the design space
of wireless sensor networks in the context of the 6LoWPAN working
group. The design space is already limited by the unique
characteristics of a LoWPAN (e.g., low power, short range, low bit
rate). In the RFC 6568, the following design space dimensions are
described; Deployment, Network size, Power source, Connectivity,
Multi-hop communication, Traffic pattern, Mobility, Quality of
Service (QoS).
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
in an organized manner. The bootstrapping has different
characteristics for each link layer technology.
o Topology: Topology of 6lo networks may inherently follow the
characteristics of each link layer technology. Point-to-point,
star, tree or mesh topologies can be configured, depending on the
link layer technology considered.
o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the
characteristics of each link layer technology. Some link layer
technologies may support L2-mesh and some may not support.
o Multi-link subnet, single subnet: The selection of multi-link
subnet and single subnet depends on connectivity and the number of
6lo nodes.
Hong, et al. Expires May 3, 2017 [Page 8]
Internet-Draft 6lo Applicability & Use cases October 2016
o Data rate: Originally, the link layer technologies of 6lo have low
rate of data transmission. But, by adjusting the MTU, it can
deliver higher data rate.
o Buffering requirements: Some 6lo use case may require more data
rate than the link layer technology support. In this case, a
buffering mechanism to manage the data is required.
o Security Requirements: Some 6lo use case can involve transferring
some important and personal data between 6lo nodes. In this case,
high-level security support is required.
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
or moved around, it requires a mobility management mechanism.
o Time synchronization requirements: The requirement of time
synchronization of the upper layer service is dependent on the 6lo
use case. For some 6lo use case related to health service, the
measured data must be recorded with exact time and must be
transferred with time synchronization.
o Reliability and QoS: Some 6lo use case requires high reliability,
for example real-time service or health-related services.
o Traffic patterns: 6lo use cases may involve various traffic
patterns. For example, some 6lo use case may require short data
length and random transmission. Some 6lo use case may require
continuous data and periodic data transmission.
o Security Bootstrapping: Without the external operations, 6lo nodes
must have the security bootstrapping mechanism.
o Power use strategy: to enable certain use cases, there may be
requirements on the class of energy availability and the strategy
followed for using power for communication [RFC7228]. Each link
layer technology defines a particular power use strategy which may
be tuned [I-D.ietf-lwig-energy-efficient]. Readers are expected
to be familiar with RFC 7228 terminology.
o Update firmware requirements: Most 6lo uses case will need a
mechanism for updating firmware. In these cases support for over
the air updates are required, probably in a broadcast mode when
bandwith is low and the number of identical devices is high.
Hong, et al. Expires May 3, 2017 [Page 9]
Internet-Draft 6lo Applicability & Use cases October 2016
6. 6lo Use Cases
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 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 after less than 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.
Hong, et al. Expires May 3, 2017 [Page 10]
Internet-Draft 6lo Applicability & Use cases October 2016
o Buffering requirements: Low requirement.
o Security requirements: Data privacy and security must be provided.
Encryption is required.
o Mobility: Most devices are static. A few devices (e.g. remote
control) are portable.
o Time Synchronization: TBD.
o Reliability and QoS: Moderate to high level of reliability
support. Actions as a result of human-generated traffic should
occur after less than 0.5 seconds.
o Traffic patterns: Periodic (sensor readings) and aperiodic (user-
triggered interaction).
o Security Bootstrapping: Required.
o Power use strategy: Mix of P1 (Low-power) devices and P9 (Always-
on) devices.
o Update firmware requirements: TBD.
6.2. Use case of Bluetooth Low Energy: Smartphone-Based Interaction
with Constrained Devices
The key feature behind the current high Bluetooth LE momentum is its
support in a large majority of smartphones in the market. Bluetooth
LE can be used to allow the interaction between the smartphone and
surrounding sensors or actuators. Furthermore, Bluetooth LE is also
the main radio interface currently available in wearables. Since a
smartphone typically has several radio interfaces that provide
Internet access, such as Wi-Fi or 4G, the smartphone can act as a
gateway for nearby devices such as sensors, actuators or wearables.
Bluetooth LE may be used in several domains, including healthcare,
sports/wellness and home automation.
Example: Bluetooth LE-based Body Area Network for fitness
A person wears a smartwatch for fitness purposes. The smartwatch has
several sensors (e.g. heart rate, accelerometer, gyrometer, GPS,
temperature, etc.), a display, and a Bluetooth LE radio interface.
The smartwatch can show fitness-related statistics on its display.
However, when a paired smartphone is in the range of the smartwatch,
the latter can report almost real-time measurements of its sensors to
the smartphone, which can forward the data to a cloud service on the
Internet. In addition, the smartwatch can receive notifications
Hong, et al. Expires May 3, 2017 [Page 11]
Internet-Draft 6lo Applicability & Use cases October 2016
(e.g. alarm signals) from the cloud service via the smartphone. On
the other hand, the smartphone may locally generate messages for the
smartwatch, such as e-mail reception or calendar notifications.
The functionality supported by the smartwatch may be complemented by
other devices such as other on-body sensors, wireless headsets or
head-mounted displays. All such devices may connect to the
smartphone creating a star topology network whereby the smartphone is
the central component.
Dominant parameters in fitness scenarios with Bluetooth LE:
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: TBD.
o Buffering requirements: Low requirement.
o Security requirements: For health-critical information, data
privacy and security must be provided. Encryption is required.
Some types of notifications sent by the smartphone may not need.
o Mobility: Low.
o Time Synchronization: the link layer, which is based on TDMA,
provides a basis for time synchronization.
o Reliability and QoS: a relatively low ratio of message losses is
acceptable for periodic sensor readings. End-to-end latency of
sensor readings should be low for critical notifications or
alarms, generated by either the smartphone or an Internet cloud
service.
o Traffic patterns: periodic (sensor readings) and aperiodic
(smartphone-generated notifications).
o Security Bootstrapping: Required.
o Power use strategy: P1 (Low-power) devices.
o Update firmware requirements: TBD.
Hong, et al. Expires May 3, 2017 [Page 12]
Internet-Draft 6lo Applicability & Use cases October 2016
6.3. Use case of DECT-ULE: Smart Home
DECT is a technology widely used for wireless telephone
communications in residential scenarios. Since DECT-ULE is a low-
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
typically acts as a base station for wireless telephones. Therefore,
DECT-ULE is specially suitable for the connected home space in
application areas such as home automation, smart metering, safety,
healthcare, etc.
Example: use of DECT-ULE for Smart Metering
The smart electricity meter of a home is equipped with a DECT-ULE
transceiver. This device is in the coverage range of the Fixed Part
of the home. The Fixed Part can act as a router connected to the
Internet. This way, the smart meter can transmit electricity
consumption readings through the DECT-ULE link with the Fixed Part,
and the latter can forward such readings to the utility company using
Wide Area Network (WAN) links. The meter can also receive queries
from the utility company or from an advanced energy control system
controlled by the user, which may also be connected to the Fixed Part
via DECT-ULE.
Dominant parameters in smart metering scenarios with DECT-ULE:
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 [I-D.ietf-roll-applicability-ami].
Hong, et al. Expires May 3, 2017 [Page 13]
Internet-Draft 6lo Applicability & Use cases October 2016
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 [I-D.ietf-roll-applicability-ami]).
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:
[TBD]
Example: [TBD]
o Power use strategy: P9 (Always-on).
6.5. Use case of NFC: Alternative Secure Transfer
According to applications, various secured data can be handled and
transferred. Depending on security level of the data, methods for
transfer can be alternatively selected. The personal data having
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: Secure Transfer by Using NFC in Healthcare Services with
Tele-Assistance
A senior citizen who lives alone wears one to several wearable 6lo
devices to measure heartbeat, pulse rate, etc. The 6lo devices are
densely installed at home for movement detection. An LoWPAN Border
Hong, et al. Expires May 3, 2017 [Page 14]
Internet-Draft 6lo Applicability & Use cases October 2016
Router (LBR) at home will send the sensed information to a connected
healthcare center. Portable base stations with LCDs may be used to
check the data at home, as well. Data is gathered in both periodic
and event-driven fashion. In this application, event-driven data can
be very time-critical. In addition, privacy also becomes a serious
issue in this case, as the sensed data is very personal.
While the senior citizen is provided audio and video healthcare
services by a tele-assistance based on LTE connections, the senior
citizen can alternatively use NFC connections to transfer the
personal sensed data to the tele-assistance. At this moment, hidden
hackers can overhear the data based on the LTE connection, but they
cannot gather the personal data over the NFC connection.
+-------------+ +-------------+
|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.
Hong, et al. Expires May 3, 2017 [Page 15]
Internet-Draft 6lo Applicability & Use cases October 2016
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
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, etc. Therefore, the use
case of LTE MTC could be used in LPWAN.
Example: Use of wireless backhaul for LoRa gateway
LoRa is one of the most promising technologies 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 has two types of backhaul, wired and
wireless backhaul.
If 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. Since
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 with above example:
Hong, et al. Expires May 3, 2017 [Page 16]
Internet-Draft 6lo Applicability & Use cases October 2016
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 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
but category 2.
Dominant parameters in controlling car scenarios with above example:
o Deployment/Bootstrapping: Pre-planned.
Hong, et al. Expires May 3, 2017 [Page 17]
Internet-Draft 6lo Applicability & Use cases October 2016
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 IEEE 802.15.4e:
[TBD]
Example: [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.
Hong, et al. Expires May 3, 2017 [Page 18]
Internet-Draft 6lo Applicability & Use cases October 2016
Samita Chakrabarti, Thomas Watteyne, Pascal Thubert, Abdur Rashid
Sangi, Xavier Vilajosana, Daniel Migault, and Take Aanstoot 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>.
Hong, et al. Expires May 3, 2017 [Page 19]
Internet-Draft 6lo Applicability & Use cases October 2016
[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>.
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-applicability-ami]
Cam-Winget, N., Hui, J., and D. Popa, "Applicability
Statement for the Routing Protocol for Low Power and Lossy
Networks (RPL) in AMI Networks", draft-ietf-roll-
applicability-ami-15 (work in progress), October 2016.
Hong, et al. Expires May 3, 2017 [Page 20]
Internet-Draft 6lo Applicability & Use cases October 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.
Authors' Addresses
Yong-Geun Hong
ETRI
161 Gajeong-Dong Yuseung-Gu
Daejeon 305-700
Korea
Phone: +82 42 860 6557
Email: yghong@etri.re.kr
Carles Gomez
Universitat Politecnica de Catalunya/Fundacio i2cat
C/Esteve Terradas, 7
Castelldefels 08860
Spain
Email: carlesgo@entel.upc.edu
Younghwan Choi
ETRI
218 Gajeongno, Yuseong
Daejeon 305-700
Korea
Phone: +82 42 860 1429
Email: yhc@etri.re.kr
Hong, et al. Expires May 3, 2017 [Page 21]
Internet-Draft 6lo Applicability & Use cases October 2016
Deoknyong Ko
SKtelecom
9-1 Byundang-gu Sunae-dong, Seongnam-si
Gyeonggi-do 13595
Korea
Phone: +82 10 3356 8052
Email: engineer@sk.com
Hong, et al. Expires May 3, 2017 [Page 22]