Skip to main content

IPv6 over Constrained Node Networks(6lo) Applicability & Use cases
draft-ietf-6lo-use-cases-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9453.
Authors Yong-Geun Hong , Carles Gomez , Abdur Rashid Sangi , Take Aanstoot
Last updated 2017-03-13
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 9453 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-6lo-use-cases-01
6Lo Working Group                                              Y-G. Hong
Internet-Draft                                                      ETRI
Intended status: Informational                                  C. Gomez
Expires: September 13, 2017                                    UPC/i2cat
                                                               Y-H. Choi
                                                                    ETRI
                                                                 D-Y. Ko
                                                               SKtelecom
                                                               AR. Sangi
                                                     Huawei Technologies
                                                          Take. Aanstoot
                                                                Modio AB
                                                          March 12, 2017

   IPv6 over Constrained Node Networks(6lo) Applicability & Use cases
                      draft-ietf-6lo-use-cases-01

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, PLC (IEEE
   1901), 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."

Hong, et al.           Expires September 13, 2017               [Page 1]
Internet-Draft        6lo Applicability & Use cases           March 2017

   This Internet-Draft will expire on September 13, 2017.

Copyright Notice

   Copyright (c) 2017 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 LE  . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  DECT-ULE  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.5.  NFC . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.6.  LTE MTC . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.7.  PLC . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.8.  IEEE 802.15.4e  . . . . . . . . . . . . . . . . . . . . .   8
   4.  6lo Deployment Scenarios  . . . . . . . . . . . . . . . . . .   9
   5.  Design Space  . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  6lo Use Cases . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Use case of ITU-T G.9959: Smart Home  . . . . . . . . . .  11
     6.2.  Use case of Bluetooth LE: Smartphone-Based Interaction
           with Constrained Devices  . . . . . . . . . . . . . . . .  13
     6.3.  Use case of DECT-ULE: Smart Home  . . . . . . . . . . . .  14
     6.4.  Use case of MS/TP: Management of District Heating . . . .  15
     6.5.  Use case of NFC: Alternative Secure Transfer  . . . . . .  17
     6.6.  Use case of LTE MTC: Gateway for Wireless Backhaul
           Network . . . . . . . . . . . . . . . . . . . . . . . . .  19
     6.7.  Use case of PLC: Smart Grid . . . . . . . . . . . . . . .  21
     6.8.  Use case of IEEE 802.15.4e: Industrial Automation . . . .  24
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  25
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  25

Hong, et al.           Expires September 13, 2017               [Page 2]
Internet-Draft        6lo Applicability & Use cases           March 2017

     10.2.  Informative References . . . . . . . . . . . . . . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

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 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), Power Line Communication (PLC), 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 and Smart grid assistance, 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

Hong, et al.           Expires September 13, 2017               [Page 3]
Internet-Draft        6lo Applicability & Use cases           March 2017

   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,
   considering the following aspects:

   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 LE

   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

Hong, et al.           Expires September 13, 2017               [Page 4]
Internet-Draft        6lo Applicability & Use cases           March 2017

   Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or
   newer.

   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.  MS/TP

   MS/TP is a contention-free access method for the RS-485 physical
   layer, which is used extensively in building automation networks.

Hong, et al.           Expires September 13, 2017               [Page 5]
Internet-Draft        6lo Applicability & Use cases           March 2017

   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
   faced in 6lowpan networks and suggest some elements of that solution
   might be leveraged.  MS/TP differs significantly from 6lowpan in at
   least three aspects: 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, although not according to standards, in lower speeds,
   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
   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 and
   very reliable field bus for the most numerous and least expensive
   devices in a building automation network [I-D.ietf-6lo-6lobac].

3.5.  NFC

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

Hong, et al.           Expires September 13, 2017               [Page 6]
Internet-Draft        6lo Applicability & Use cases           March 2017

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

   Unlike other dedicated communication infrastructure, the required
   medium (power conductor) is widely available indoors and outdoors.
   Moreover, wire d technologies are more susceptible to cause
   interference but are more rel iable than their wireless counterparts.
   PLC is a data transmission techniq ue that utilizes power conductors
   as medium.

   The below figure shows some available open standards defining PLC.

Hong, et al.           Expires September 13, 2017               [Page 7]
Internet-Draft        6lo Applicability & Use cases           March 2017

   +-------------+-----------------+------------+-----------+----------+
   | PLC Systems | Frequency Range |    Type    | Data Rate | Distance |
   +-------------+-----------------+------------+-----------+----------+
   |   IEEE1901  |     <100MHz     | Broadband  |  200Mbps  |  1000m   |
   |             |                 |            |           |          |
   |  IEEE1901.1 |      <15MHz     |  PLC-IoT   |   10Mbps  |  2000m   |
   |             |                 |            |           |          |
   |  IEEE1901.2 |     <500kHz     | Narrowband |  200Kbps  |  3000m   |
   +-------------+-----------------+------------+-----------+----------+

               Table 2: Some Available Open Standards in PLC

   [IEEE1901] defines broadband variant of PLC but is effective within
   short range.  This standard addresses the requirements of
   applications with high data rate such as: Internet, HDTV, Audio,
   Gaming etc.  Broadband operates on OFDM (Orthogonal Frequency
   Division Multiplexing) modulation.

   [IEEE1901.2] defines narrowband variant of PLC with less data rate
   but significantly higher transmission range that could be used in an
   indoor or even an outdoor environment.  It supports operating either
   in Low Voltage (LV) or High Voltage (HV) segment of PLC domain.  It
   is applicable to typical IoT applications such as: Building
   Automation, Renewable Energy, Advanced Metering, Street Lighting,
   Electric Vehicle, Smart Grid etc.  Narrowband operates either on FSK
   (Frequency Shift Keying), S (Spread) FSK, BPSK (Binary Phase Shift
   Keying), SS (Spread Spectrum) or OFDM modulation.  Moreover, IEEE
   1901.2 standard is based on the 802.15.4 MAC sub-layer and fully
   endorses the security scheme defined in 802.15.4.  [RFC8036].

   Specific applications come with requirement of diversity.  Although
   IEEE1901 offers higher data rate but is not applicable for long
   distance scenario due to losses in higher frequencies.  On the other
   hand, IEEE1901.2 is not applicable for real-time services due to low
   data rate.  The IEEE 1901.1 WG is working on a new standard, namely
   [IEEE1901.1], that provides extended transmission range as compared
   to IEEE1901 and higher data rate than IEEE1901.2 [IEEE1901.2].  More
   intelligent IoT financial services are emerging such as: Self Service
   Terminal, Bank Transfer, Scratch Card, POS (point of sale) etc. and
   require extensive data transfers.  This standard is also known as
   PLC-IoT and operates on OFDM modulation e.g.  FTT (Fast Fourier
   Transform) and/or wavelet OFDM.

3.8.  IEEE 802.15.4e

   The Timeslotted Channel Hopping (TSCH) mode was introduced in the
   IEEE 802.15.4-2015 standard.  In a TSCH network, all nodes are
   synchronized.  Time is sliced up into timeslots.  The duration of a

Hong, et al.           Expires September 13, 2017               [Page 8]
Internet-Draft        6lo Applicability & Use cases           March 2017

   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 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:

      - 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 scenarios 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).

Hong, et al.           Expires September 13, 2017               [Page 9]
Internet-Draft        6lo Applicability & Use cases           March 2017

   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.

   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.

Hong, et al.           Expires September 13, 2017              [Page 10]
Internet-Draft        6lo Applicability & Use cases           March 2017

   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 use cases 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.

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

Hong, et al.           Expires September 13, 2017              [Page 11]
Internet-Draft        6lo Applicability & Use cases           March 2017

   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.

   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.

Hong, et al.           Expires September 13, 2017              [Page 12]
Internet-Draft        6lo Applicability & Use cases           March 2017

6.2.  Use case of Bluetooth LE: 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: Use of 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
   (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.

Hong, et al.           Expires September 13, 2017              [Page 13]
Internet-Draft        6lo Applicability & Use cases           March 2017

   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.

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.

Hong, et al.           Expires September 13, 2017              [Page 14]
Internet-Draft        6lo Applicability & Use cases           March 2017

   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 [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
   as BACnet and some use of ModBus, the defacto standard for low
   bandwith industry communication.  Specially Modbus has been around
   since the 1980 and is still the standard for talking to fans, heat
   pumps, water purifying equipment and everything else delivering
   electricity, clean water and ventilation.

Hong, et al.           Expires September 13, 2017              [Page 15]
Internet-Draft        6lo Applicability & Use cases           March 2017

   Example: Use of MS/TP for management of district heating

   The mechanical room in the cellar of an apartment building gets
   district heating and electricity from the utility providers.  The
   room has a Supervisory Control And Data Acquisition (SCADA) computer
   talking to a centralized server and command center somewhere else
   over IP, on the other hand it is controlling the heating, fans and
   distribution panel over a 2-wire RS-485 based protocol to make sure
   the logic controller for district heating keeps a constant
   temperature at the tapwater, the logic controller for heat produktion
   keeps the right radiator temperature depending on the weather and the
   fans have a correct speed and are switched off in case district
   heating fails to prevent cooling out the building and give certain
   commands in case smoke is detected.  Speed is not important, in this
   usecase, 19,200 bit/s capable equipment is sold as high speed
   communication capable.  Reliability is important, this not working
   will easily give millions of dollars of damage.  Normally the setup
   is that the SCADA device asks a question to a specific controlling
   device, gets an answer from the controlling device, asks a new
   question to some other device.

   o  Deployment/Bootstrapping: Pre-planned.

   o  Topology: Bus, master-slave, token-passing.

   o  Multi-link subnet, single subnet: [TBD], normally single.

   o  Data rate: Small data rate, frequent transmissions.

   o  Buffering requirements: Low.

   o  Security requirements: Security must be provided, authentication
      is a must.

   o  Mobility: Highly static

   o  Time synchronization: Required.

   o  Reliability and QOS: High, Alerts have to arrive properly, timing
      is not important.  Implication of failing reliability has high
      probability for life-or-death implications (fire-alarms) or
      millions of dollars of liability (frozen water heating system in a
      high rise building)

   o  Traffic patterns: Constant sensor readings and asking devices for
      error reporting.

   o  Security Bootstrapping: Nice to have, not very important.

Hong, et al.           Expires September 13, 2017              [Page 16]
Internet-Draft        6lo Applicability & Use cases           March 2017

   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
   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: Use of NFC for Secure Transfer 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
   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.

Hong, et al.           Expires September 13, 2017              [Page 17]
Internet-Draft        6lo Applicability & Use cases           March 2017

       +-------------+                              +-------------+
       |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

Hong, et al.           Expires September 13, 2017              [Page 18]
Internet-Draft        6lo Applicability & Use cases           March 2017

      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.

Hong, et al.           Expires September 13, 2017              [Page 19]
Internet-Draft        6lo Applicability & Use cases           March 2017

   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.

Hong, et al.           Expires September 13, 2017              [Page 20]
Internet-Draft        6lo Applicability & Use cases           March 2017

   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
   measuring sub-systems of an electric grid.  It comprises of multiple
   administrative levels/segments to provide connectivity among these
   numerous components.  Last mile connectivity is established over LV
   segment, whereas connectivity over electricity distribution takes
   place in HV segment.

   Although other wired and wireless technologies are also used in Smart
   Grid (Advance Metering Infrastructure - AMI, Demand Response - DR,
   Home Energy Management System - HEMS, Wide Area Situational Awareness
   - WASA etc), PLC enjoys the advantage of existing (power conductor)
   medium and better reliable data communication.  PLC is a promising
   wired communication technology in that the electrical power lines are
   already there and the deployment cost can be comparable to wireless
   technologies.  The 6lo related scenarios lie in the low voltage PLC
   networks with most applications in the area of Advanced Metering
   Infrastructure, Vehicle-to-Grid communications, in-home energy
   management and smart street lighting.

   Example: Use of PLC for Advanced Metering Infrastructure

   Household electricity meters transmit time-based data of electric
   power consumption through PLC.  Data concentrators receive all the
   meter data in their corresponding living districts and send them to
   the Meter Data Management System (MDMS) through WAN network (e.g.
   Medium-Voltage PLC, Ethernet or GPRS) for storage and analysis.  Two-
   way communications are enabled which means smart meters can do
   actions like notification of electricity charges according to the
   commands from the utility company.

   With the existing power line infrastructure as communication medium,
   cost on building up the PLC network is naturally saved, and more
   importantly, labor operational costs can be minimized from a long-
   term perspective.  Furthermore, this AMI application speeds up
   electricity charge, reduces losses by restraining power theft and
   helps to manage the health of the grid based on line loss analysis.

   Dominant parameters in smart grid scenarios with PLC:

Hong, et al.           Expires September 13, 2017              [Page 21]
Internet-Draft        6lo Applicability & Use cases           March 2017

   o  Deployment/Bootstrapping: Pre-planned.

   o  Topology: Tree topology.

   o  L2-mesh or L3-mesh: No.

   o  Multi-link subnet, single subnet: Single subnet.

   o  Data rate: Small data rate, infrequent transmissions.

   o  Buffering requirements: Low requirement.

   o  Security requirements: Data privacy and security must be provided.
      Encryption is required.

   o  Mobility: Static.

   o  Time Synchronization: Low requirement.

   o  Reliability and QoS: a relatively low ratio of message losses is
      acceptable for periodic meter readings.

   o  Traffic patterns: Periodic (upstream meter reading notifications
      sent by the meter) and aperiodic (utility company-triggered
      downstream queries and messages to the meter such as notification
      of electricity charges or leak detection).

   o  Security Bootstrapping: Required.

   o  Power use strategy: Mix of P1 (Low Power) devices and P9 (Always-
      on) devices.

   o  Update firmware requirements: TBD.

   Example: Use of PLC (IEEE1901.1) for WASA in Smart Grid

   Many sub-systems of Smart Grid require low data rate and narrowband
   variant (IEEE1901.2) of PLC fulfils such requirements.  Recently,
   more complex scenarios are emerging that require higher data rates.
   (see Table 3).

Hong, et al.           Expires September 13, 2017              [Page 22]
Internet-Draft        6lo Applicability & Use cases           March 2017

    +--------------+----------+--------------+-------------+---------+
    |  Sub System  | Security |  Bandwidth   | Reliability | Latency |
    +--------------+----------+--------------+-------------+---------+
    |     HEMS     |   High   |  9.6-56kbps  |     99%     | <2000ms |
    |              |          |              |             |         |
    |   AMI-Node   |   High   |  10-100kbps  |     99%     |  <200ms |
    |              |          |              |             |         |
    | AMI-Backhaul |   High   |   500kbps    |     99%     |  <200ms |
    |              |          |              |             |         |
    |     WASA     |   High   | 600-1500kbps |     99%     |  <200ms |
    +--------------+----------+--------------+-------------+---------+

                  Table 3: Some Sub Systems of Smart Grid

   WASA sub-system is an appropriate example that collects large amount
   of information about the current state of the grid over wide area
   from electric substations as well as power transmission lines.  The
   collected feedback is used for monitoring, controlling and protecting
   all the sub-systems.

   Dominant parameters in WASA scenario with above example:

   o  Deployment/Bootstrapping: Pre-planned.

   o  Topology: TBD.

   o  L2-mesh or L3-mesh: TBD.

   o  Multi-link subnet, single subnet: TBD.

   o  Data rate: TBD.

   o  Buffering requirements: TBD.

   o  Security requirements: TBD.

   o  Mobility: TBD.

   o  Time Synchronization: TBD.

   o  Reliability and QoS: TBD.

   o  Traffic patterns: TBD.

   o  Security Bootstrapping: TBD.

   o  Power use strategy: P9 (Always-on).

Hong, et al.           Expires September 13, 2017              [Page 23]
Internet-Draft        6lo Applicability & Use cases           March 2017

   o  Update firmware requirements: TBD.

6.8.  Use case of IEEE 802.15.4e: Industrial Automation

   Typical scenario of Industrial Automation where sensor and actuators
   are connected through the time-slotted radio access (IEEE 802.15.4e).
   For that, there will be a point-to-point control signal exchange in
   between sensors and actuators to trigger the critical control
   information.  In such scenarios, point-to-point traffic flows are
   significant to exchange the controlled information in between sensors
   and actuators within the constrained networks.

   Example: Use of IEEE 802.15.4e for P2P communication in closed-loop
   application

   AODV-RPL [I-D.ietf-roll-aodv-rpl] is proposed as a standard P2P
   routing protocol to provide the hop-by-hop data transmission in
   closed-loop constrained networks.  Scheduling Functions i.e. SF0
   [I-D.ietf-6tisch-6top-sf0] and SF1 [I-D.satish-6tisch-6top-sf1] is
   proposed to provide distributed neighbor-to-neighbor and end-to-end
   resource reservations, respectively for traffic flows in
   deterministic networks (6TiSCH).

   The potential scenarios that can make use of the end-to-end resource
   reservations can be in health-care and industrial applications.
   AODV-RPL and SF0/SF1 are the significant routing and resource
   reservation protocols for closed-loop applications in constrained
   networks.

   Dominant parameters in P2P scenarios with above example:

   o  Deployment/Bootstrapping: Pre-planned.

   o  Topology: TBD.

   o  L2-mesh or L3-mesh: TBD.

   o  Multi-link subnet, single subnet: TBD.

   o  Data rate: TBD.

   o  Buffering requirements: TBD.

   o  Security requirements: TBD.

   o  Mobility: TBD.

   o  Time Synchronization: TBD.

Hong, et al.           Expires September 13, 2017              [Page 24]
Internet-Draft        6lo Applicability & Use cases           March 2017

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

Hong, et al.           Expires September 13, 2017              [Page 25]
Internet-Draft        6lo Applicability & Use cases           March 2017

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

Hong, et al.           Expires September 13, 2017              [Page 26]
Internet-Draft        6lo Applicability & Use cases           March 2017

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.

Hong, et al.           Expires September 13, 2017              [Page 27]
Internet-Draft        6lo Applicability & Use cases           March 2017

   [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

   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

Hong, et al.           Expires September 13, 2017              [Page 28]
Internet-Draft        6lo Applicability & Use cases           March 2017

   Younghwan Choi
   ETRI
   218 Gajeongno, Yuseong
   Daejeon  305-700
   Korea

   Phone: +82 42 860 1429
   Email: yhc@etri.re.kr

   Deoknyong Ko
   SKtelecom
   9-1 Byundang-gu Sunae-dong, Seongnam-si
   Gyeonggi-do  13595
   Korea

   Phone: +82 10 3356 8052
   Email: engineer@sk.com

   Abdur Rashid Sangi
   Huawei Technologies
   No.156 Beiqing Rd. Haidian District
   Beijing  100095
   P.R. China

   Email: rashid.sangi@huawei.com

   Take Aanstoot
   Modio AB
   S:t Larsgatan 15, 582 24
   Linkoping
   Sweden

   Email: take@modio.se

Hong, et al.           Expires September 13, 2017              [Page 29]